Git Rules

      Усі ми були початківцями у чомусь. Ось, пригадую свої перші навчальні проекти та відповідно перші кроки з Git та GitHub. Моєю ціллю тоді було лише пушити та коммітити на GitHub. І коли все проходило без помилок … Фух!!! Пролізло… Який там коментар? Абра-кадабра в кращомому випадку, а то одна буква для позначення. Комміти відслідковувалися по даті й часу. Ні, так не можна!!! Беріть приклад не з мене, це точно!!! Раджу одразу, намагатися дотримуватися кращих практик роботи з Git.

Git disco logo
Бла-ла-ла-ла !!!

По-перше: Вивчайте Git !

Знати, де шукати — це половина успіху подолати квест.”

      Пропонуємо ознайомитися із дописом: Лікбез по Git — більшість представлених ресурсів українською мовою. Або вивчайте будь-які ресурси рекомендовані іншими людьми. Я ж закликаю кожного, прочитати хоча би книгу Pro Git BOOK. Ви повинні розуміти Ваші дії, котрі Ви проробляєте!

Додавайте в один Git -commit пов’язані зміни

       Так і є, Ви усе правильно зрозуміли кожен окремий комміт мусить бути логічно продуманим і містити пов’язані зміни. Git створено для того, аби Ви розділяли завдання, і комміти були незалежними один від одного.

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

     Окрім того маленькі комміти допомагають іншим розробникам після Вас простіше зрозуміти чужі зміни.

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

А ще радимо коммітити у репозиторій часто

      Часта публікація коммітів одночасно дозволяє робити їх дрібними і, знову ж таки, допомагає додавати в комміти тільки пов’язані зміни.

      Більш того, слід частіше ділитися своїм кодом з колегами. Таким чином, всім буде легше, якщо Ви частіше будете інтегрувати свої зміни. Це допоможе уникнути конфліктів при злитті.

Великі і рідкісні комміти ускладнюють життя і ускладнюють вирішення проблем. Навпаки чим менші та модульніші комміти, тим менше шансів припуститися помилок, котрі не підлягають виправленню.

Не панікуйте, якщо щось зробили не так

       Основи Git дуже прості, але варто попасти у нестандартну ситуацію, і Ви можете почувати себе цілком заплутаним. Ситуацію ще підсилює той факт, що при невірному вирішенні ризикуєте цілком втратити свої дані. Насправді, з Git дані втратити ДУЖЕ важко, бо рішення може бути приховане в такому місці, у котре складно добратися, не маючи достатніх знань. Дізнайтеся у Git про скасування, видалення та виправленя Git-команди. У багатьох випадках  комміт можливо пофіксити без втрати даних.

        Варіанти скористуватися reset, rebase, cherry-pick, merge.

     Команди за допомогою яких наймовірніше віднайти втрачені дані reflog (git log -g), (git fsck –unreachable), (git stash list), (gitk –all –date-order), (git ls-tree -r).

        Але пам’ятайте будь-які дії з відновленя можуть знищити поточну роботу!

Ні в якому разі не публікуйте комміти з незакінченою роботою

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

      Але не публікуйте зміни тільки заради того щоби в репозиторії щось з’явилося перед відходом з офісу в кінці робочого дня. Якщо збираєтеся опублікувати комміт тільки тому, що потрібна чиста робоча область (при перемиканні гілок, перед pull і т.д.) придивіться до функціональності “stash”.

Тестуйте та перевіряйте свій код перед Git commit -ом

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

Пишіть хороші коментарі

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

Яка була причина змін?
Чим відрізняється цей комміт від попереднього комміту?

          Використовуйте слова в теперішньому часі («змінюється», не «змінено» або «зміни»), для того щоб при git merge згенероване повідомлення виглядало добре.

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

Запам’ятайте система контролю версій це не сховище бекапів

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

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

      При роботі з системою зверніть особливу увагу на семантику коммітов (дивись попередні пункти)  Ви не повинні просто так запихати файли в репозиторій.

Використовуйте гілки

       Розгалуження  це одна з найпотужніших можливостей Git. І це не випадково: швидке й просте галуження було вимогою номер один з самого початку. Гілки є найпростішим інструментом уникнути змішування різних ліній розробки, а Ви щоб могли легко переключатися між задачами. Ви повинні повсюдно використовувати гілки в своїй розробці: для роботи над новими завданнями, для виправлення багів, для ідей …але також не зловживайте цим правилом. Усе повинне бути в міру.

Узгодьте робочий процес

     Git дозволяє вибрати з великої кількості робочих процесів: довгі гілки, тематичні гілки, злиття або переміщення, gitflow … Що з цього буде вибрано? залежить від декількох факторів: Вашого проекту, загального напрямку розробки, середовища розробки та (можливо найважливіше) Ваших особистих побажань і побажань команди. Однакових проектів та підходів із цієї точки зору не має.

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

Підсумок:

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.