Чи не саме вичерпне, але точно цілком дохідливо керівництво по Git, Github і Gitflow - для тих, кого ці слова бентежать, хоча не повинні.
Контроль версій допомагає не тільки уникнути прикрих косяків при внесенні змін, але і необхідний для командної роботи над проектом. У цьому матеріалі ми розглянемо основні команди для консолі і розберемо найпопулярнішу модель управління гілками проекту. І про гілки теж поговоримо.
Git - це розподілена система контролю версій (version control system - VCS).
Контроль версій означає що ви зберігаєте всі версії редагованих документів і можете повернутися до будь-якої збереженої версії в будь-який момент часу. Здається, ніби такий підхід популярний тільки серед програмістів, але на ділі їм користуються, наприклад, дизайнери та інші люди, кілька більш підковані технічно, щоб контролювати зміни в роботі.
Розподіленість git'а відрізняє його від інших vcs. Під распределенностью слід розуміти, буквально, можливість використання однієї системи контролю на проекті безліччю розробників.
До слова, Git створив ось цей ввічливий джентельмен:
Для початку, переконайтеся, що у вас встановлений Git.
Тепер, все що нам знадобиться, щоб створити репозиторій, це команда git init в потрібному каталозі.
Відкрийте командний рядок, і перейдіть в Desctop (так, будемо оригінальні), а там створіть каталог (наприклад, proglib).
Тепер, проходимо в новий каталог і виконуємо git init.
Все, у нас є порожній репозиторій.
Давайте створимо простий README.md файл, щось на кшталт:
Тепер, коли ви знаєте наскільки просто працювати з розгалуженням, вас не здивує, що у багатьох людей своєрідний підхід до управління гілками.
Але є один підхід, який популярний в співтоваристві. Знайомтеся, популярна модуль управління гілками Gitflow:
Схема виглядає безладно, коли бачиш її вперше, так що підемо по порядку. У нас є дві основні гілки: master і develop.
У гілці master міститься рівно той же код, що і в робочій (читай, продакт) версії проекту. А вся робота робиться в гілці develop.
Під час роботи на основі develop створюються так звані feature-гілки. Їх може бути необмежена кількість.
Далі, у нас є гілка release, яка використовується для підготовки до нового релізу проекту.
Нарешті, є гілка hotfix, яка служить для термінового виправлення багів, знайдених, наприклад, на продакт.
Ось як в теорії, відбувається робочий процес в Gitflow:
1. Створюється репозиторій
2. Репозиторий инициализируется
3. Починається робота на гілці develop
4. Виникає необхідність випробувати нову штуку - створюється feature-гілка і робляться коммітов
5. Закінчивши роботу на feature-гілці, ви зливаєте її з develop
6. Якщо ви задоволені поточною версією, але хочете продовжити роботу, створюється гілка release, куди переміщається поточна версія. Виправлення багів буде відбуватися на цій же гілці.
7. Коли з гілкою release покінчено, час злити її в master і продовжити роботу з develop
8. Крім того, цей момент можна відзначити на master-гілці
Проробимо описане вище крок за кроком, але для початку переконайтеся, що у вас є gitflow-avh - інструмент для роботи з Gitflow. На маці його можна встановити за допомогою homebrew:
brew install git - flow - avh
gitflow-avh - це колекція розширень для git, яка допомагає уникнути багатьох повторюваних операцій і взагалі робить життя простіше (це не точно). Наприклад, при роботі з feature-гілкою, утиліта перевірить, злилася вона в develop і видалить її, якщо все пройшло добре. Звичайно, можна слідувати моделі Gitflow і самостійно, роблячи операції руками, але ж простіше ж використовувати готове рішення, так?
Далі буде кілька питань, але якщо залишити опції за замовчуванням, ця команда просто створить і назве гілки у відповідність з моделлю Gtiflow.
Коли все закінчиться, ви побачите, що знаходитеся на гілці develop. Тепер, створимо нову feature-гілку:
git - flow feature start new_docs
Потім, відкриємо README.md і внесемо зміни. Після, зробимо Комміт:
git commit - m "Added new documentation»
Тепер, якщо ми всім задоволені, закінчимо з цією гілкою:
git - flow feature finish new_docs
Як можна бачити у висновку в консолі, ця команда зробила наступне:
1. злилися гілки new_docs і develop
2. Удалила new_docs
3. Виконала перехід на гілку develop, щоб можна було продовжувати роботу
Припустимо, нова фіча нас влаштовує, вона відтестувати і працює справно. Тепер нам потрібно зробити реліз.
Для початку, необхідно виконати команду:
git - flow release start 2.0
Тут можна внести будь-які останні потенційні виправлення, оновити версію (має значення при розробці мобільних додатків) і так далі.
Коли робота закінчена, просто напишемо:
git - flow release finish 2.0
Вам потрібно буде додати кілька повідомлень і міток, а потім утиліта зробить наступне:
1. зіллється release і master
2. Позначити release як 2.0
3. зіллється release і develop
4. Видалить release
5. Чи виконає перехід на develop
Іноді спільна робота нагадує класику:
На гітхабе ви можете додати когось, кого ви знаєте в співробітники в налаштуваннях Settings-Collaborators. Запрошені таким чином учасники отримають дозвіл пушіть в ваше сховище або ви можете створити команду розробників і регулювати рівні доступу від проекту до проекту.
Але навіть якщо ви добре знаєте людину, вам не завжди може сподобається, що хтось робить коммітов в майстер без вашого відома. Для таких випадків в github сущест pull-request'и і code review.
Працює це таким чином: ви робите якесь поліпшення або фікс на featire-гілці, робите pull request, хтось із старших розробників, які курують проект дивиться ваш код (читай, робить code review), можливо, робить якісь зауваження і , в кінцевому підсумку додає ваш код в майстер-гілку (або кудись ще).
На ділі відношення до код рев'ю може бути різним. Буквально, від
І як же до відноситься до code review? Скінчено, це дуже важлива штука і потрібно мати терпіння і робити рев'ю всіх пул реквестов, якщо мова йде про ваш проект, наприклад. У довгостроковій перспективі це окупиться. І, звичайно, легко сказати «just do it», але в деяких випадках сформовані традиції в команді розробників можуть змусити переглянути своє ставлення до деяких речей.
Створимо нову feature-гілку: