Как объяснить, почему ветвление + слияние лучше, чем непрерывное вытягивание + pu sh для ветвей, над которыми работают несколько человек?

Question

Скажем, есть ветка, над которой работают несколько разработчиков, которая называется TestBranch

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

1:

• Разработчики вносят изменения
• Прежде чем они наберут sh, они тянут последние изменения от всех остальных с git pull origin TestBranch (или просто git pull)
• справиться с любыми конфликтами слияния
• git push origin TestBranch (или просто git push), чтобы все остальные получили свои изменения

2:

• git checkout -b MyBranch (или ветка с последующей проверкой), чтобы создать собственную личную ветку для работы.
• Когда они имеют выполнив подзадачу, они делают git checkout TestBranch
• git pull, чтобы получить последние изменения на TestBranch (не будут вызывать слияния, так как они не коснулись TestBranch, просто fast-forward),
• git merge MyBranch
• Обработка любых конфликтов слияния
• git push origin TestBranch, чтобы все остальные получили свои изменения

Второй В целом метод требует немного больше работы, но история варианта # 1 git - это кошмар, особенно для более чем пары разработчиков. Это огромное поле пересекающихся линий, тонны узлов, которые не являются реальным содержимым и т. Д. c.

Как мне это объяснить? Есть хороший пример, может быть, картинка, что-то, чтобы сказать, почему выполнение # 1 - плохая идея в долгосрочной перспективе?

(Или, если я ошибаюсь, не стесняйтесь говорить мне об этом)

Answer 1

Во-первых, мое личное мнение заключается в следующем, и я знаю по опыту, что обсуждение git рабочих процессов может быть весьма горячим c, поскольку некоторые решения по вкусу.

---

Однако уже есть несколько (очень распространенных) стратегий ветвления (рабочих процессов) для решения этой и других проблем. Atlassian имеет довольно хороший обзор нескольких моделей.

Для вашей конкретной проблемы c, если вы хотите иметь чистую историю git и работаете только на одной ветви Вы думали сделать git pull --rebase до git push (если вы работаете над TestBranch)? Это дало бы вам «красивую» и прямую историю коммитов, без каких-либо дополнительных затрат (конфликты слияния должны быть исправлены в любом случае)

Если люди работают с определенными c блоками (скажем, новыми функциями или исправлениями), введение ветки 'feature' или 'fix' обычно является хорошей идеей и аналогично тому, что вы предложили в (2). Это также добавляет хорошую область для фиксации, поэтому, когда ветки имеют четкое имя (скажем, feature/tooltip), вы мгновенно узнаете, где также искать изменения для этой функции. Разница в том, что вы предлагаете, заключается в том, что ветви не ограничиваются пользователем, работающим над ним, а скорее функцией / исправлением, которое оно содержит. Так что это может привести к тому, что несколько (но, как правило, несколько, так как эти ветви должны быть недолговечными) разработчики работают над одной веткой.

Кроме того, если я правильно понимаю ваши два подхода, оба метода создадут одинаковое количество Слияние конфликтов и ветвей, поэтому я не вижу улучшения в (2).