рабочий процесс git: у каждого есть ветка, или у каждого есть мастер?

Question

При работе с несколькими людьми с помощью git, лучше

1. , чтобы все просто работали в мастере и сливались между мастерами друг друга, или
2. , чтобы все работали всвою собственную ветвь с названием?

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

Может кто-то с опытом работына средних и крупных командах с git делать какие-либо комментарии?Что лучше всего подходит для вашей команды?Я предполагаю, что третий вариант - всегда использовать ветви функций вместо ветвей людей, хотя я вижу, что это в основном та же самая ситуация, что и (2) с точки зрения этого вопроса.

Я представляю, что в обоих (1) и (2) один человек несет ответственность за внесение изменений в «официального» мастера.Как это перенесется, если более одного человека будут толкать доступ к официальному мастеру?

Answer 1

Имена ветвей в git являются локальными для репозитория. push и pull могут быть настроены на совпадение идентичных имен в удаленном репозитории, но это необязательное поведение. Если у вас есть центральное хранилище, вы хотите, чтобы master был окончательным. То, что отдельные разработчики называют своими рабочими ветвями в своих локальных репозиториях, - дело вкуса. Некоторые будут иметь свою локальную master рабочую ветвь, а другие будут использовать одну именованную ветку dev.

Если ваши разработчики в этом разбираются, то действительно разумный способ - использовать ветки функций или тем, чтобы вместо ветки «Работа Майка» у вас была ветка «Работа над функцией автозаменивания», которую можно перемещать и обменивать. разумно, без того, чтобы всем нужно было делать кучу ранних слияний туда-сюда.

Answer 2

Для команды среднего и большого размера вам, скорее всего, понадобится централизованное хранилище с «официальной» веткой master.

Другой популярный вариант - иметь интегратора, который в основном является посредником между разработчиками и центральным репо. То, как вы решите это, зависит от того, что ваша команда решит, является наиболее подходящим методом. В Pro Git book .

есть отличная информация о различиях.

Начиная с общего репо, все сводится к личным предпочтениям разработчиков (и некоторым групповым соглашением), фиксировать ли их непосредственно в локальном master или использовать отдельную ветку dev. Я думаю, что сохранение локальных изменений в ветке dev является лучшим вариантом, но немного более обременительным для разработчиков, которые привыкли к централизованному SCM.

Преимущество отдельной ветви dev заключается в том, что она упрощает отслеживание новых коммитов в базе кода, просто запустив git pull на master. Чистый мастер позволяет разработчикам всегда проверять последний открытый код, если это необходимо. Если вы pull с изменениями в master, он объединится в ветке origin/master с вашими неопубликованными коммитами. Это создаст новый коммит слияния в master и будет видимым, если изменения когда-либо будут возвращены к master. Может быть, это то, что вы хотите, но это может сделать историю коммитов несколько беспорядочной.

С веткой dev вы можете легко сделать ребаз против master, чтобы сохранить историю коммитов линейной. Без dev ответвления git pull --rebase в master будет иметь тот же эффект, но этот шаг легко забыть.

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

Answer 3

DVCS представляет публикацию как отогональное измерение к ветвлению .

Это означает, что ветви в DVCS имеют две роли:

1. классический: изоляция кода : вы изолируете историю (список ревизий) кода в ветви
2. новый: публикация: вы повторяете свои коммиты из репо в репо.

Git допускает «частные коммиты», т.е. вы делаете столько, сколько хотите (и тогда вы можете очистить свою историю коммитов ).
Если вы сделаете это в master, это не подходит для публикации: поскольку master - это ветвь, видимая по умолчанию при клонировании репо, любой, кто клонирует репо, не получит стабильное состояние, но снимок незавершенного производства.

Частные коммиты означают: коммит в ветвях, которые не опубликованы.
Вы можете называть их как хотите.

Любая ветвь, которую нужно протолкнуть / вытащить, никогда не должна вызываться после имени ресурса (например, VonC_branch), но всегда после функции или более общей темы управления выпуском (например, public), next ',' patchV1 ', ...)

Разница между частными и общедоступными ветвями заключается в истории коммитов, которые вы разрешаете в каждом из них:

• столько коммитов, сколько вы хотите в частной ветке (вам нужно просто назначить правильный комментарий для облегчения будущего повторного заказа через rebase --interactive с действиями !fixup и !squash)
• "непротиворечивые" коммиты в открытых ветвях (каждый коммит завершен, представляет стабильное состояние, которое по крайней мере компилируется и может быть протестировано, даже если этот тест не пройден)
  Например, основная ветвь будет иметь более строгий стандарт, чем этот (например, "тесты должны пройти)

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