Простой пример разработки в команде технического проекта
Рассмотрим простой пример групповой разработки, который может использоваться в команде технического проекта.
К этому моменту существует удалённый репозиторий, в который конвертирована конфигурация из основного хранилища. Руководитель проекта создал в нём ветку tech-project/000001, в которой будет вестись разработка. В команде проекта есть два разработчика: Андрей и Василий.
Первый разработчик, Андрей, клонирует удалённый репозиторий. Для этого он переходит в перспективу
Git и в панели
Репозитории Git выполняет команду
Клонировать
репозиторий Git. Для разработки ему нужна только ветка
tech-project/000001, поэтому в мастере клонирования репозитория он отмечает только её.
Затем он делает изменения и создаёт локальный коммит 88a45e3 ().
Второй разработчик, Василий, выполняет то же самое — клонирует удалённый репозиторий и делает коммит с изменениями e81fdd8.
Теперь Василий отправляет свою работу на сервер ().
История коммитов его локального репозитория и история коммитов удалённого репозитория становятся одинаковыми.
Андрей также пытается отправить свои изменения на сервер.
Андрей не может выполнить отправку изменений, так как за это время Василий уже отправил свои. Это очень важно понять, так как мы видим, что эти два разработчика не редактировали один и тот же объект. При использовании Git'а, даже если редактировались разные объекты, вы должны слить коммиты локально.
Прежде чем Андрей сможет отправить свои изменения на сервер, он должен извлечь наработки Василия и затем выполнить слияние. Это выполняется одной командой .
Слияние прошло без проблем — история коммитов Андрея теперь выглядит как на рисунке:
Теперь Андрей может протестировать свой код, дабы удостовериться, что он по-прежнему работает нормально, а затем отправить свою работу, уже объединённую с работой Василия, на сервер.
В результате история коммитов Андрея выглядит, как показано на рисунке:
Тем временем, Василий работал над тематической веткой. Он создал тематическую ветку с названием Проект54 () и сделал три коммита в этой ветке. Он ещё не получал изменения Андрея, так что его история коммитов выглядит, как показано на рисунке:
Василий хочет синхронизировать свою работу с Андреем, так что он извлекает изменения с сервера ().
Эта команда извлекает наработки Андрея, которые он успел выложить. История коммитов Василия теперь выглядит как на рисунке.
Теперь Василий может слить ветку tech-project/000001 со своей тематической веткой, слить свою ветку tech-project/000001 с работой Андрея ( origin/tech-project/000001), и затем отправить изменения на сервер.
Сначала он переключается на свою основную ветку tech-project/000001, чтобы объединить всю эту работу ().
Он может слить сначала ветку origin/tech-project/000001, а может и Проект54 — обе они находятся выше в истории коммитов, так что не важно, какой порядок слияния он выберет. Конечное состояние репозитория должно получиться идентичным независимо от того, какой порядок слияния он выберет; только история коммитов будет немного разная.
Он решает слить ветку Проект54 первой ().
Никаких проблем не возникло. Как видите, это была обычная перемотка.
Теперь Василий сливает работу Андрея ( origin/tech-project/000001).
Слияние проходит нормально, и теперь история коммитов Василия выглядит так, как показано на рисунке.
Теперь указатель origin/tech-project/000001 доступен из ветки tech-project/000001 Василия, так что он может спокойно отправить изменения на сервер (полагая, что Андрей не выкладывал свои изменения за это время):
В результате история коммитов Василия выглядит так, как показано на следующем рисунке. Каждый разработчик несколько раз выполнял коммиты и успешно сливал свою работу с работой другого.
Это один из простейших рабочих процессов. Вы работаете некоторое время, преимущественно в тематической ветке. Когда вы готовы поделиться этой работой с другими, вы сливаете её в ветку tech-project/000001, извлекаете изменения с сервера и сливаете origin/tech-project/000001 (если за это время произошли изменения), и, наконец, отправляете свои изменения в ветку tech-project/000001 на сервер. Общая последовательность действий выглядит так, как показано на рисунке:
Обновление ветки репозитория по состоянию основного хранилища
Через некоторое время после начала разработки технического проекта в основном хранилище было исправлено несколько ошибок. Руководитель проекта решает обновить репозиторий до состояния основного хранилища.
Для этого он получает изменения из удалённого репозитория ().
При этом, как вы видите, в ветку master будут получены изменения, выполненные в основном хранилище, и перенесенные в репозиторий автоматически, конфигурацией 1С:ГитКонвертер. А в ветку tech-project/000001 будут получены изменения, выполненные за это время Андреем и Василием.
В результате история коммитов у руководителя проекта будет выглядеть следующим образом:
Основная
ветка у него
tech-project/000001, поэтому он может выполнить
Получить и слить для того, чтобы слить её с изменениями Андрея и Василия (
origin/tech-project/000001).
В результате его история коммитов будет выглядеть следующим образом:
Теперь он может слить свою локальную ветку tech-project/000001 с удалённой веткой origin/master, чтобы объединить локальную ветку с изменениями, появившимися в основном хранилище.
В результате его история коммитов будет выглядеть следующим образом:
После этого он тестирует прикладное решение, дабы удостовериться, что оно по-прежнему работает нормально. А после этого отправляет ветку tech-project/000001 на сервер, чтобы Андрей и Василий могли использовать обновлённую версию разрабатываемого прикладного решения.
В результате история коммитов на сервере выглядит следующим образом.
Руководитель проекта оповещает Андрея и Василия о том, что он обновил ветку технического проекта. Поэтому Андрей, прежде чем начать очередные изменения, сначала получает с сервера последние изменения и сливает их со своей локальной веткой ().
В результате Андрей имеет у себя ту же историю коммитов, которая находится на удалённом сервере.
