Как рационально использовать GIT

Вчера код работал, сегодня нет
Код был удален
Появилась ошибка и никто не имеет представления почему

Если у вас была такая ситуация, то эта статья для вас.

Не считая знания команд git add, git commit и git push, есть еще несколько важных техник в Git. И их знание, в общем то, сильно поможет. Здесь я расскажу о некоторых вещах, которые помогут вам использовать Git на все сто.

Процесс работы с Git

Каждый раз, когда несколько разработчиков внедрены в проект, важно правильно организовать ход работы с Git`ом. Я рассмотрю процесс, который эффективен в больших проектах с командой разработчиков.

Надеюсь, эта схема работы поможет вам в представить весь процесс работы с Git.

Алгоритм

Внезапно, Вам поручили руководить проектом в котором вы планируете разработать новый Facebook. У вас в команде три разработчика:

1. Элис: интерн, новичок в программировании
2. Боб: имеет год опыта в программировании и знает как программировать
3. Джон: имеет три года опыта в программировании и хорошо в этом разбирается
4. Вы: назначены руководить проектом

Процесс разработки в Git

Master-ветка

1. Master-ветка всегда должна иметь копию уже существующего кода в продакшене.
2. Никто, включая руководителя, не должен работать с master-веткой напрямую, если нет копии проекта в production-ветке.
3. Новый и актуальный код должен храниться в других ветках.

Release-ветка

1. Когда работа над проектом начинается, первая вещь которую нужно сделать — создать release-ветку для проекта. Она создаётся из master-ветки.
2. Весь код, принадлежащий проекту, должен находиться в release-ветке. Release-ветка это просто ветка с префиксом release/.
3. Для примера назовем ее release/fb.
4. Возможно, что несколько проектов используют один и тот же код как основу проекта. Так что для проекта создана отдельная release-ветка. Припустим, что еще один проект разрабатывается параллельно. Тогда, проект будет иметь иную release-ветку: release/messenger.
5. Определенная база кода может использоваться для нескольких проектов одновременно. Во имя избежания конфликтов необходимо создавать для каждого проекта отдельную release-ветку.

Feature-ветка

1. Для каждого нововведения, внедряемого в программу, создаётся feature-ветка. Это гарантирует, что нововведения будут встраиваться независимо.
2. Feature-ветка идентична любой другой ветке, но с префиксом feature/.
3. Сейчас Вы, будучи руководителем проекта, попросили Элис построить login-экран для Facebook. Она создает новую feature-ветку для этого. Назовем ее feature/login. Элис будет писать весь код этого нововведения только в этой feature-ветке.
4. Feature-ветка создаётся, как правило, из release-ветки.
5. Бобу было поручено сделать страничку поиска друзей. Так что он создает feature-ветку с названием feature/friendrequest.
6. Задача Джона сделать новостную ленту. Джон создает feature-ветку названую feature/newsfeed.
7. Все разработчики работают в своих feature-ветках. Пока все хорошо 🙂
8. Допустим что Элис закончила работу и ее код готов. Ей нужно отправить его в release-ветку release/fb из своей feature-ветки feature/login. Это делаеться при помощи pull request`a.

Pull запрос

Прежде всего, не нужно путать pull запрос с git pull.

Разработчик не должен вносить изменения (Прим. переводчика: пушить) напрямую в release-ветку. Руководитель проекта обязан проверить код нововведения перед его добавлением в release-ветку.

Элис может выполнить pull запрос, как предлагает GitHub — эти шаги возможны только на GitHub`е.

Сразу возле имени ветки есть опция, названая “Новый pull запрос”. При нажатии на неё открывается новый экран показанный ниже:

Здесь:

• compare-ветка должна соответствовать feuture-ветке Элис feature/fb
• base-ветка должна cоответствовать release-ветке release/fb

Как только это будет выполнено, Элис нужно ввести имя и описание для всего pull запроса и нажать на кнопку “Создать Pull Запрос”. Элис также нужно назначить обозревателя запроса. Она вводит Ваше имя, так как вы руководитель.

После этого руководитель проекта просматривает код в запросе и соединяет код feautre-ветки с кодом release-ветки.

Сейчас мы совместили код из feature/login-ветки вместе с кодом release/fb-ветки и Элис рада, что ее код был добавлен. 🙂

Конфликты кода

1. Боб закончил свой код и создал pull запрос для соединения feature/friendrequest и release/fb.
2. Так как release-ветка включает в себя login-код —  произойдет конфликт. Разрешать конфликты и соединять код —  ответственность обозревателя. В этом случае, Вы, как руководитель должны решить проблему и соединить код.
3. Сейчас Джон закончил работу над своим кодом и хочет добавить его в release-ветку. Но Джон неплохо разбирается в конфликтах. Он добавляет актуальный код из release/fb-ветки в свою ветку feature/newsfeed (при помощи git pull или git merge). Джон решает все имеющиеся конфликты. Сейчас ветка feature/newsfeed хранит весь код release/fb-ветки.
4. Теперь, когда конфликтов в коде уже нет, Джон делает pull request.

Так что есть два пути решения конфликтов:

• Первый: тот, кто мониторит pull запросы, должен решать конфликты.
• Второй: разработчик делает так, что последний актуальный код из release-ветки добавлен в его feature-ветку и рашает конфликты сам.

И снова о master-ветке

Как только проект закончен, код из release-ветки сливается обратно в master-ветку. Теперь код развернут в продакшене. Таким образом, код в продакшене и в master-ветке всегда синхронизированы. Обновленный код всех будущих проектов будет также доступен в master-ветке.

Перевод статьи Aditya Sridhar: How to use Git efficiently