Закрытый проект с менеджером
В этом сценарии мы рассмотрим роли разработчиков в более крупном закрытом проекте. Вы научитесь работе в окружении, где маленькие группы совместно работают над задачами, а затем результаты их деятельности интегрируются отдельным субъектом.
Давайте представим, что Андрей и Василий работают вместе над одной задачей (назовём её featureA), в то время как Василий и третий разработчик, Николай, работают над другой (назовём её featureB). В этом случае компания использует рабочий процесс с менеджером по интеграции, при котором работа частных групп объединяется только определёнными менеджерами, и ветка master основного репозитория обновляется только этими менеджерами. В этом случае вся работа выполняется в ветках отдельных команд разработчиков и впоследствии объединяется воедино менеджерами.
Давайте проследим за рабочим процессом Василия, который работает над двумя задачами одновременно, взаимодействуя одновременно с двумя разными разработчиками. Положим, что он уже склонировал основной репозиторий. Сначала он решает заняться задачей featureA. Он создаёт новую ветку для этой задачи и выполняет в ней некоторую работу.
На этом этапе ему требуется поделиться своей работой с Андреем, так что он отправляет коммиты, выполненные на ветке featureA, на сервер. Так как Василий не имеет права на изменение ветки master на сервере (только менеджеры могут делать это), он вынужден отправлять свои изменения в другую ветку, чтобы обмениваться работой с Андреем.
Василий сообщает по электронной почте Андрею, что он выложил некоторые наработки в ветку featureA, и что Андрей может проверить их.
Пока Василий ждёт ответа от Андрея, он решает начать работу над веткой featureB вместе с Николаем. Для начала он создаёт новую ветку для этой задачи, используя в качестве основы ветку master на сервере.
Теперь Василий делает пару коммитов в ветке featureB.
Василий уже готов отправить свою работу на сервер, но получает от Николая сообщение о том, что некоторые наработки уже были выложены на сервер в ветку featureBee. Поэтому Василий должен сначала слить эти изменения со своими, прежде чем он сможет отправить свою работу на сервер. Он может извлечь изменения Николая командой .
Теперь Василий может слить эти изменения в свои наработки командой .
Есть небольшая проблема: ему нужно выложить изменения из своей ветки featureB в ветку featureBee на сервере. Он может сделать это, настроив для неё refspec.
Для этого Василий переключается в перспективу
Git, в панели
Репозитории Git раскрывает удалённый репозиторий и на
push-ветке выполняет команду
Настроить
отправку....
В открывшемся окне он нажимает Добавить... чтобы создать новое соответствие ссылок (refspec).
В данном случае ему нужно задать соответствие между ссылкой на локальную ветку и ссылкой на удалённую ветку.
Он заполняет поля оба поля так, как показано на рисунке. Поле Specification 1C:EDT заполняет автоматически.
После этого Василий нажимает ОК. В списке Ref mappings он видит свою новую запись и закрывает диалог, нажимая Сохранить.
Теперь он может отправить свои изменения на сервер ().
Обратите внимание, что, как Василий и хотел, его локальная ветка featureB была отправлена на сервер в ветку featureBee. В результате его история коммитов имеет следующий вид.
Далее, Андрей сообщает Василию по почте, что он добавил некоторые изменения в ветку featureA, и просит её проверить их. Василий выполняет , чтобы получить внесённые Андреем изменения.
Наконец, он сливает работу Андрея в свою собственную ветку featureA.
Василий хочет кое-что подправить, так что он опять делает коммит и затем отправляет изменения на сервер.
Василий, Николай и Андрей информируют менеджера, что ветки featureA и featureBee на сервере готовы к интеграции в основную ветку разработки. После того, как менеджер интегрируют эти ветки в основную версию, извлечение данных с сервера приведёт к появлению нового коммита слияния. История коммитов Василия, например, станет выглядеть следующим образом.
Множество команд разработчиков переходят на Git именно из-за возможности параллельной работы нескольких команд с последующим объединением разных линий разработки. Огромное преимущество Git'а это возможность маленьких подгрупп большой команды работать вместе через удалённые ветки, не мешая при этом всей команде. Последовательность событий в рассмотренном здесь рабочем процессе представлена на следующем рисунке.
