Какие процессы рабочего процесса в команде вы используете в отношении git?

Я собираюсь переместить мою команду из TFS в GIT в ближайшем будущем, но прежде чем я это сделаю, я хочу знать о любых подводных камнях, которые другие могли испытывать при перемещении команды из централизованного источника управления таких как CVS, SVN, TFS и т.д. в систему управления распределенным источником, такую ​​как GIT или Mercurial.

Некоторые вопросы, которые мгновенно пришли на ум:

  • Работает ли каждый пользователь своей ветки на сервере, а затем сливается, когда это делается, или они просто остаются локальными на своих машинах и после этого нажимают на сервер?

  • Должны ли все новые разработки работать на ветке (т.е. "следующая версия" ) или должны быть выполнены против "master"?

  • Должна ли новая разработка быть сделана в клоне на сервере, а затем выдавать запросы на тягу к базе производственного кода или быть достаточно хорошей ветвью базы производственного кода?

  • Следуйте за номером 3, если все делается на ветке, есть ли способ контролировать, кто может делать слияния в "master"?

  • Есть ли что-нибудь еще, о чем я должен беспокоиться, что я не думаю о том, что произошло в вашем движении от централизованного контроля версий до распределенного контроля версий?

Однако мое настоящее любопытство и вопрос касаются того, как вы управляете своими процессами работы над GIT и другими системами управления распределенными источниками, а не тем, что подходит для моего текущего процесса документооборота.

Обновление: В настоящее время процесс разработки в TFS состоит в том, что у нас есть главная папка, а затем папка ветки для материала следующей версии, и когда код следующей версии завершен, он объединяется в в главную папку. Каждый член команды имеет полные права на осуществление всего проекта. У нас нет сложного процесса по какой-либо части воображения, мы до сих пор использовали наш источник управления как просто немой репозиторий.

Однако, как говорится, я ищу больше идеального процесса обработки ситуации, а не что-то, что соответствует моему текущему процессу. Вот почему я назвал вопрос What team workflow processes do __you__ use concerning GIT?

ОТВЕТЫ

Ответ 1

Обратите внимание, что я не использовал Git в корпоративной среде, и ответы ниже основаны на моем опыте работы над проектами OSS с Git и моим пониманием Git.

См. также gitworkflows (7) manpage.

  • Работает ли каждый пользователь своей ветки на сервере и затем сливается, когда это делается, или они просто остаются локальными на своих машинах и после этого нажимают на сервер?

В любой системе управления распределенной версией и в любом рабочем процессе, использующем DVCS, каждый пользователь имеет свой собственный частный репозиторий, не являющийся голым, в котором он или она выполняет свою работу. Обычная практика заключается в том, что пользователь не публикует свою работу до ее готовности.

Публикация одной работы может означать нажатие на некоторый центральный репозиторий, или это может означать нажатие на один собственный публичный репозиторий; из этого публичного репозитория разработчика поддерживающий (или эквивалентный) может вытащить изменения.

Ознакомьтесь с хорошим описанием (с диаграммами!) возможных рабочих процессов в Глава 5.1: Распределенные рабочие процессы Pro Git. Proffesional Version Control CC-лицензионная книга Скотта Чакона.

  • Должны ли все новые разработки работать над веткой (т.е. "следующая версия" ), или это должно быть сделано против "мастера"?

Рекомендуемый рабочий процесс (но, конечно, не единственный возможный) состоит в том, чтобы развить каждую отдельную функцию на отдельной ветки, так называемые ветки . Когда функция считается готовой, она объединяется в "следующую" (ветвь развития) или в "мастер" (стабильная ветвь).

[...]

  • Есть ли что-нибудь еще, о чем я должен беспокоиться, что я не думаю о том, что произошло в вашем движении от централизованного контроля версий до распределенного контроля версий?

Если у вас большие и часто изменяющиеся двоичные файлы, то работать с системой управления распределенной версией может быть сложнее настроить; то централизованная система управления версиями может быть лучше.

Ответ 2

Из ваших вопросов я чувствую, что ваше мышление по-прежнему зависит от централизованной системы контроля версий. В распределенной системе сервер больше не "рабочее место", а просто зеркало коллективной работы. Таким образом, это даже не обязательно.

Обычно в центральном репозитории нет ничего, кроме ветки master и тегов выпуска. Это должно отражать только общий фактор. Филиалы в распределенной системе очень конфиденциальны и поэтому должны оставаться локальными.

В моей работе над моим частным репозиторием у меня есть следующие ветки:

  • master является точным отражением центрального master. Я никогда не занимаюсь этим. Вместо этого я только вытаскиваю из центрального зеркала в свой master.
  • develop-* - это набор ветвей функции (работы), которые отходят от ветки release. Например, у меня может быть ветвь с именем develop-foo_performance, где я настраиваю производительность класса Foo. Или, возможно, у меня есть ветка с названием develop-cosmetics, где я накапливаю некоторые незначительные косметические фиксации. Это, в основном, недолговечные ветки для очень специфических задач. Это ветки проекта; Я делаю это постоянно, свободно записывая сообщения о фиксации и не задумываясь о том, "является ли это изменение достойным совершения". Это мои личные ошибки, скрывающие историю отслеживания Ctrl-S.
  • release - это ветвь, в которую я сквошу, готов к публикации. Когда я закончил кодирование своей конкретной идеи для настройки производительности для Foo на ветке develop-foo_performance, я, вероятно, буду иметь набор неорганизованных коммитов, экспериментирующих в разных направлениях. Я переустанавливаю эти коммиты в ветвь release, вызывая их в логические привязки, ориентированные на объекты, - часто одно коммит. Этот сквош отбрасывает весь код, который не заканчивается в конечном состоянии, поэтому история, которую показывает release, очень чистая и линейная; все эксперименты исчезли, как будто я совершенный разработчик, чем могу видеть в будущем, никогда не ошибаюсь и не замечает описательных целей. В конце дня я нажимаю ветвь release на центральное зеркало, а затем извлекаю удаленный master и объединяя его в свой master.
  • napkin - моя личная ветка заметок. Его корневая фиксация отличается от корня master. Я никогда не сливаю или не переустанавливаю эту ветку в какую-либо другую, никогда не подталкиваю ее или не втягиваю в нее, никогда не объединяю ничего здесь. Здесь я храню свой файл todo, найденные ошибки, мои личные заметки, идеи, вопросы для размышлений или любые другие документы, которые можно бесплатно писать. Это непересекающаяся ветвь, и это для моего личного способа делать вещи: никто никогда ее не видит. Это держит меня организованным и ясным.

Для любого проекта, который у меня есть, будь то на работе или дома, это единственные ветки, которые у меня есть. Я создаю новые ветки develop-* и удаляю полные и неудачные. Другие ветки никогда не умирают и никогда не утихают. Обратите внимание, что при объединении удаленного master в my master слияние должно быть быстрым. Это потому, что я никогда не совершаю в свой собственный master - только втягиваю его.

Этот рабочий процесс поддерживает разработчика интеграции; разработчик, отвечающий за интеграцию других людей, работает в центральной ветки master. Если люди никогда не вступают в свою личную ветку master, то у них есть гарантия, что их личный master выглядит точно так же, как и у производственной кодовой базы. Это безопасная сеть, поэтому люди всегда могут от нее отказаться, если им нужна чистая кодовая база.

Если два разработчика хотят поделиться опытом, они могут отправлять друг другу запросы на перенос или отправлять сообщения по электронной почте с помощью git format-patch. Это распределенная работа в лучшем виде: общение происходит между сверстниками, а людям, которые не интересуются экспериментом, не нужно это видеть. Они остаются целенаправленными, и проект выглядит для них меньше и проще.

Ответ 3

Я использовал этот рабочий поток, где в нашей организации: http://nvie.com/posts/a-successful-git-branching-model/

Мы настраиваем управление тем, кто может делать то, что к ветки через гитолит.

Это был хороший "хвост света, который следует за туманом". Благодаря бесконечным параметрам, которые дает вам Git, вам сложно принять решение о том, каким должен быть ваш рабочий поток. Начните с этого и приспосабливайтесь. Это сработало для нас очень хорошо. Мы используем стек .net с ароматом OSS (NHibernate и т.д.)

Ответ 4

Git формирует вашу потребность, а не наоборот (как это происходит с централизованными системами управления версиями).

Если вы расскажете нам, как вы управляете своими разработками и выпусками, мы можем сказать вам, какой рабочий процесс в GIT подойдет.

Изменить: Что касается обновления, вы можете легко выполнить этот рабочий процесс в git. Вопрос в том, что вам больше нужно от инструмента управления версиями. Сделать изменение только потому, что мы хотим изменения, это не очень хорошая идея.