Знакомство с рабочим процессом git для небольшой команды

Question

Интересно, если это разумный подход к использованию Git с небольшой командой:

1. У нас есть "мастер" филиал. Git создает эту ветку для нас по умолчанию.
2. Разработчик A и B клонируют "мастера" на свои локальные машины.
3. Разработчик A запускает: [git branch devA] для создания локальной ветки. Они переключаются на него, запустив: [git checkout devA].
4. Разработчик B запускает: [git branch devB] для создания локальной ветки. Они переключаются на него, запустив: [git checkout devB].
5. Чтобы Разработчик А превратил свою локальную ветвь в удаленную, они должны выполнить: [git push origin devA]. Разработчик B делает то же самое со своей локальной веткой.
6. Теперь, если вы используете GitHub, мы увидим эти две удаленные ветви на странице нашего проекта.
7. Оба разработчика вносят изменения в свои локальные ветви, и при запуске [git push] их коммиты отправляются в соответствующие удаленные ветви (мы увидим, что это отражено на github).

Мне кажется, это разумный рабочий процесс. Теперь пришло время разработчикам объединить всю свою работу для выпуска приложения, над которым они работают. Мое понимание:

1. Разработчик A хочет внести изменения Разработчика B в свою ветку. Разработчик A запустит: [git pull origin devB].
2. Мы могли бы создать еще одну удаленную ветку с именем "dev", которая действует как центральное хранилище для всех изменений: [git branch dev], [git push origin dev].
3. Один из разработчиков переключается на ветку "dev". Они вносят в него все изменения: [git pull origin devA], [git pull origin devB]. Все конфликты исправлены и т. Д.
4. После того, как все конфликты исправлены в «dev», мы переключаемся на ветку «master» и вставляем в нее «dev»: [git ветка master], [git pull origin dev].

Таким образом, идея заключается в том, что все разработчики работают в своих локальных ветвях и периодически объединяют вещи в "dev". Только во время выпуска кто-то вытягивает изменения из «dev» в «master». Таким образом, «master» всегда содержит последний выпущенный код.

Это кажется разумным?

Спасибо!

Answer 1

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

Он не отражает общую философию Git, согласно которой каждая ветвь представляет одну "функцию" или "тему".- стоимость работы (см., например, Хунио Хамано по назначению филиалов ).Однако это не помешает ему стать работоспособным рабочим процессом для вашей команды.

Популярным рабочим процессом, отражающим эту философию, является git flow .

Другим популярным рабочим процессом является рабочий процесс, который команда разработчиков GitHub использует , что прямо противоречит тому, что пишет Junio ​​о слиянии мастера с ветвями функций, в пользу, по-видимому, упрощения ментальной модели и исключения необходимости объяснения перебазирования разработчикам.

Другая проблема заключается в том, что этот рабочий процесс препятствует частой интеграции.Поэтому devA и devB могут значительно различаться, и разработчикам, возможно, придется проделать большую работу для объединения, когда придет время.

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

Answer 2

Если у вас более двух разработчиков, хотите ли вы, чтобы один разработчик мог получать изменения от одного другого конкретного разработчика, но не включать изменения от всех других разработчиков? Если нет, я не вижу необходимости создавать какие-либо ветки для разработчиков вообще. Каждый регистрируется, чтобы освоить собственный репозиторий; каждый подталкивает к осознанию происхождения; каждый получает все сдвинутые изменения, объединенные от всех разработчиков, при каждом нажатии.

Что касается ветки master против dev в источнике, вы можете сделать это; хотя, как правило, я думаю, что master - это постоянная работа, и каждый стабильный выпуск имеет свою ветвь.