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