Skip to content

Files

Latest commit

 

History

History
executable file
·
288 lines (174 loc) · 19.8 KB

lesson07.md

File metadata and controls

executable file
·
288 lines (174 loc) · 19.8 KB

Знайомство з Git

Передмова, історія проблеми

Після болісної роботи зі звичайним копіюванням файлів багато хто зіткнувся з тим, що командна розробка стає тим складнішим, чим більше людей у ній бере участь. Найбільше проблем виникає, коли люди працюють над одними й тими самими файлами.

Ілюстрація з перекладу статті розробника Warcraft Патріка Вайата:

"...коли я почав активно працювати з іншими художниками та розробниками, ми зазвичай використовували «пішохідну локалку», тобто по суті носили один одному з офісу в офіс флоппі-диски зі змінами, які необхідно було впровадити в код або дизайн.

Боб Фітч був другим розробником на проекті і ми з ним постійно копіювали файли та зміни у коді між собою. Періодично ми помилялися при інтеграції та баги, які ми вже фіксували, відкривалися заново. Ми виловлювали їх знову і виявляли, що коли копіювали файли, вносили зміни - ми перезаписували щось поверх вдалих баг-фіксів, і часом доводилося згадувати, як ми вже закривали ці баги заново.

І ця ситуація повторювалася все частіше і частіше, адже ми прискорювалися в розробці, а жодного іншого процесу для контролю версій, окрім методу «запам'ятовування де і що ми редагували», у нас не було. Мені певною мірою пощастило більше, адже мій комп'ютер зберігав «майстер» гілку нашого коду, куди ми додавали патчі, тому мої зміни в коді губилися рідше. Сьогодні для цього ми використовуємо системи контролю версій, але тоді ми навіть не могли собі уявити такі радості життя!"

перша частина статті друга частина статті

Отже, основна проблема - перезаписування неактуального коду поверх актуального, втрата актуального коду.

Були зроблені спроби контролювати людський чинник, розподіляти файли між розробниками, але це все лише ускладнило.

Основи: команда diff

Вже 1974 року існувала юніксова команда diff.

Нижче наведено приклад простого тексту.

1qweqwe
2erfevef
3efvercer
4vfvrvtr
6dvdfvdfv

У наступному лістингу той самий текст трохи змінено з метою демонстрації програми diff.

1qweqwe
3efvercer
4vfvrvtr
5owiceowcno
6dvdfvdfv

Маючи два практично ідентичні файли, можна за допомогою команди diff з ключами -uN зрозуміти, яка між ними різниця:

diff -uN test.txt test1.txt:

--- test.txt	2023-03-04 16:34:31.000000000 +0200
+++ test1.txt	2023-03-04 16:34:57.000000000 +0200
@@ -1,5 +1,5 @@
 1qweqwe
-2erfevef
 3efvercer
 4vfvrvtr
+5owiceowcno
 6dvdfvdfv

Команда diff працює для двох різних файлів. Система контролю версій відстежує зміни в тому самому файлі різних версій.

Системи контролю версій

Потім стали замислюватися над тим, щоб обмежити всі складнощі, що виникають і керувати проблемами за допомогою коду і автоматизації, стали винаходити різні програми для цих цілей.

Програми, які дозволяють зберігати різні файли та різні версії цих файлів, порівнювати файли та різні їх версії, мати можливість переходити між різними версіями файлів, називаються Системами контролю версій.

Види систем контролю версій

Перша, найпростіша СКВ - це просто резервне копіювання файлів.

Можна зберігати все у файл, або записувати в БД інфу про файли та їх версії, але суть не змінюється - все зберігається на локальному комп'ютері.

Другий, більш просунутий варіант - централізована СКВ. Суть такого підходу – зберігання коду на сервері та використання на локальних машинах.

Писк моди в даному питанні - розподілена СКВ.

Зміни робляться на локальних машинах, а версії зберігаються і на них, і на сервері.

Ось цей хлопець – Лінус Торвальдс.

Він колись і вигадав GIT, про який ми сьогодні і поговоримо.

Встановлення GIT

Для того, щоб встановити git під windows, спробуйте ось це посилання. Установка там проста, треба погоджуватися на початкові установки та натискати кнопку Next.

Створення локального репозиторію, команда init

Припустимо, що в системі стоїть git.

Для початку роботи нам потрібна порожня папка у зручному місці та відкрита консоль у цій папці. Створюємо пусту папку, заходимо туди. Якщо у вас git bash, клацніть правою кнопкою по порожньому місці в папці і виберіть git bash here.

Опинившись у порожній папці, ми створюємо там порожній локальний git репозиторій: git init

Стандартна відповідь:

Initialized empty Git repository in /Users/bandy/sites/form/.git/

Команда git init створює в папці нову підпапку .git, в якій git зберігає всі необхідні йому дані. Цю папку краще не чіпати. Після цього всі зміни у файлах, які знаходяться в цій папці або в папках глибше за цю, знаходяться під контролем версій. Git буде бачити зміни у файлах, але які зміни зберегти в який момент і в яких файлах - вирішувати програмісту.

Отже, локальний репозиторій створено.

Статуси файлів, команди status, add, commit, config, log

У локальному репозиторії, як і будь-якій звичайній папці, можуть бути файли і папки. Відмінність локального репозиторію від звичайної папки на жорсткому диску в тому, що за змінами файлів і папок стежить система контролю версій. Файли може бути неотслеживающимися тобто. тими, що не знаходяться під контролем версій, що відстежуються, зміненими та підготовленими до коміту. Розглянемо ці стани докладніше:

statuses

  • Невідстежуваний (untracked) - спочатку файли та папки у локальному репозиторії є невідстежуваними. Якщо файл хоч один раз додавався під контроль версій, він вже відслідковується.
  • Відстежуваний (tracked) - файл вже під контролем версій git, але з часу останнього збереження до нього не вносилися зміни.
  • Змінений (modified) - файл під контролем версій і в ньому є незбережені зміни, які поки не проіндексовані.
  • Проіндексований або підготовлений до коміту (staged) - у файлі є зміни, які проіндексовані та будуть збережені у найближчому коміті.

Поняття індексування досить просте. Є якийсь індекс (index, stage), який є набором змін у файлах. Це ті зміни, що знаходяться під контролем версій, і які програміст запланував зберегти у найближчому збереженні – коміті.

Простежимо за статусом файлу index.html на нашому локальному репозиторії, для цього додамо в наш репозиторій файл (просто скопіюємо або перемістимо файл до нашої папки) і подивимося на його статус:

git status

status

Виявлено файл index.html, який поки не доданий до планів на збереження. Додамо цей файл за допомогою команди git add index.html та перевіримо статус після цього:

status2

За допомогою команди git add можна додавати файл, групу файлів, папку з файлами або навіть файли маски до індексу. Додаються як файли, що не відстежуються, так і змінені, і всі вони стають проіндексованими. Все додане при найближчому коміті буде збережено.

Якщо внести зміни до файлу index.html після того, як ми додали його до індексу, файл у нас буде одночасно і зміненим і проіндексованим:

status3

Git працює не з цілими файлами і не з рядками цих файлів. Мінімальними одиницями інформації в git є зміни у файлах, виконані з минулого збереження.

Збереження кожного файлу можна додавати або не додавати до планів на майбутнє збереження версії. Додані будуть збережені при найближчому збереженні версії, які не додані залишитися незбереженими.

Рекомендується перевіряти статус репозиторію часто та уважно.

Продовжимо, проіндексуємо зміни та спробуємо їх зберегти за допомогою команди git commit -m comment:

config

Більшість зі студентів буде виведено щось схоже. Git повідомляє нам, що для підпису коммітів йому потрібно знати email та ім'я користувача. Команди

git config --global user.name "username"
git config --global user.email "usermail"

допоможуть внести потрібні зміни. Не забудьте замінити username та usermail на свої нікнейм та пошту.

Повторимо спробу комміту (git commit -m"comment"):

commit

Ми зберегли версію нашого коду під контролем версій. Зверніть увагу на опцію -m у команди. Вона дозволяє задати короткий коментар до комиту, якщо її не застосувати, запуститься редактор, з якого ще треба вміти вийти (trollface)

Перевіримо ситуацію із збереженнями командою git log:

log

Команда покаже нам журнал наших комітів. Там можна побачити унікальний номер комміту, дату і час збереження, а також короткий коментар. Вихід із журналу - буква q

Робота з віддаленим репозиторієм, ssh, ключі

Далі нам необхідно створити віддалений репозиторій на якомусь сервері або підключитися до готового. Можна користуватися будь-яким сервером віддалених репозиторіїв, але найпопулярнішим є github.

Якщо ви там вже зареєстровані, увійдіть туди, залогуйтесь. Далі необхідно подружити між собою локально встановлений git і вибраний сервер віддалених репозиторіїв.

Є два шляхи для їх спілкування: https та ssh. HTTPS - досить простий шлях, ми спробуємо складніший і цікавіший шлях SSH. Перше посилання в програмі допоможе вам створити такі ключі.

Для створення репозиторію необхідно натиснути кнопку new та заповнити форму створення нового репозиторію.

У полі Repository name необхідно ввести ім'я репозиторію, яке одночасно буде не надто великим і водночас інформативним.

Після того, як репозиторій створений, його треба підключити до локального репозиторію.

git remote add origin %%serverpath%%
git remote -v
git pull origin master
$ git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin master

Гіт лається, каже, гілка не задана, сервер не заданий, він не розуміє, куди пушити. Пояснимо:

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 789 bytes | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To https://github.com/Bandydan/custom
   003085e..775d992  master -> master

І зробимо так, щоб він більше не сварився:

git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

Перелік основних команд

git add filename # Додавання файлу filename до індексу
git add * # Додавання всіх файлів до індексу
git add. # Додавання всіх файлів до індексу

git rm filename # Видалення файлу з індексу

git status # Перегляд статусу локального репозиторію

git commit # Додавання з індексу до зліпок/ Потрібно ввести коментар
git commit -m "comment" # Додавання з індексу в зліпок з швидким введенням коментаря

git diff # Порівняння гілок, робочої директорії та індексу та інші порівняння

git diff --cached # порівняння проіндексованих змін з непроіндексованою версією коду

git reset # Скасування змін

git push # Залити закоммічені зміни на сервер
git fetch # Завантажити нові зміни з сервера (без злиття)
git pull # Завантажити нові зміни з сервера (зі злиттям)


git checkout # Перейти на гілку
git checkout -b # Перейти на нову гілку і створити її
git checkout filename # скасувати всі зміни у файлі

git branch # видаляє, створює та перераховує гілки

Корисні посилання

Мануал зі створення rsa ключів

Правила розміщення проекту в A-level Gitlab

Книги про GIT

Manual

Git Branching

Детальніше про всі команди git

Швидкий старт з GIT

Онлайн книга про Git

Домашнє завдання

Восьмий Урок