Когда несколько программистов работают над одним проектом, практически всегда они используют систему контроля версий для совместной работы с одним исходным кодом. Это может быть
git,
svn,
perforce и другие.
В данной статье описывается один из способов комфортного взаимодействия программистов. Стоит сразу отметить, что данный метод не претендует на звание «the best git workflow ever» и будет постоянно дорабатываться и улучшаться.
Мы используем
OS X,
VSCode,
BitBucket,
SourceTree и
git. Поэтому в примерах будут использоваться именно эти инструменты.
0. Зачем нам это?
Классический пример:
Система контроля версий - не идеальна. Потерять код во время синхронизации с чужими изменениями - горе в команде 😭. Подход, который изложен ниже поможет минимизировать побочные эффекты системы контроля версий.
1. Начало работы
Реализация каждой задачи выполняется в отдельной ветке разработки. Перед тем как начать программирование, необходимо создать отдельную ветку:
git checkout -B my-task
git push --set-upstream origin my-task
Дерево коммитов выглядит так:
В то время, как программист вносит изменения в свою ветку my-task, другие изменения появляются в основной ветке разработки. Как правило, в конце выполнения задачи дерево коммитов выглядит так:
2. Перенос своих изменений «вверх»
В статье
merging-vs-rebasing от подробно расписаны стратегии синхронизации. Мы используем rebasing.
Команда rebase переносит коммиты наверх из вашей ветки в ветку разработки. Команды:
git checkout my-task
git rebase develop
следует читать «переносим изменения my-task наверх ветки develop»
Коммиты «переносятся наверх» последовательно. Обычно «перенос» каждого коммита происходит автоматически. Но иногда автоматически «перенести» (или «накатить» коммит) не удается и тогда можно увидеть подобное сообщение:
Пояснение с скрину:
1. программист выполнил команду rebase
2. система не смогла автоматически исправить «накатить» коммит
3. система говорит, что нужно сделать. Также в редакторе VSCode подсвечивается проблемное место
После
исправления конфликта выполнить указания системы (см. пункт 3):
git add .
git rebase --continue
Эти две команды указывают, что все конфликты в коде разрешены и необходимо продолжить «перенос». Ситуация может повторятся несколько раз. В таком случае всегда следует читать логи и следовать инструкциям системы git.
После завершения переноса необходимо «запушить перенос на сервер bitbucket» c флагом force:
git push -f origin my-task
После переноса дерево коммитов выглядит так:
3. Проверка кода
После того, как «изменения перенесены наверх», необходимо на сайте bitbucket создать pull request. Для этого необходимо на соответствующей странице нажать кнопку «Create pull request»
Выглядит это так:
Пояснение к скрину:
1. Выбрать ветку, в которой велась разработка (my-task)
2. Выбрать ветку, в которую «вливаем» изменения (develop)
3. Проверить список коммитов, убедиться что ничего не было потеряно.
4. Выставить галочку, так как ветка (my-task) будет неактуальна.
Опять нажать кнопку «Create pull request»
Появится окно:
Пояснение к скрину:
1. «Влить» все данные my-task в ветку develop
2. Просмотреть весь код и указать статус «Approve»
3. Все изменения вместе
4. Завершение задачи
После нажатия кнопки «Merge» данные попадут в главную ветку разработки. После синхронизации кода с сервером получится такое «закрытие» в истории коммитов:
Пояснение к скрину:
1. Красивое дерево истории коммитов
2. Все коммиты вместе для более легкого восприятия задачи в целом
Ветку задачи my-task желательно удалить. Она более не нужна. При доработках задачи желательно создавать новую ветку (см пункт 1)
Теперь можно смело приступать к новой задаче и держать эту инструкцию под рукой.
