Каков наилучший подход к работе над моей собственной веткой с меньшим количеством конфликтов слияния с веткой X?
Используйте кратковременные, сфокусированные функциональные ветки вне ветви X. Просто потому, что все остальные не означают, что вы не можете. Использование кратковременных ветвей функций вне X сводит к минимуму отклонения X от вашей ветви функций и уменьшает конфликты.
Создайте ветку, внедрите одну вещь в свою ветку и как можно быстрее объедините ветку с X, прежде чем X сможет дрейфовать слишком далеко. В идеале ваши филиалы должны длиться несколько дней, если не часов.
После того как вы закончили свою задачу и объединили свою ветку, не используйте ее повторно. Удали это. Создайте новую ветку из X для следующего задания.
Рабочий процесс для решения этой проблемы аналогичен переходу от мастера, за исключением того, что вы переходите от X.
Вот иллюстрация вашего хранилища с ответвлением Y от X. Y устарел.
A - B [origin/master]
\
C - D - G - H [origin/X]
\
E - F [Y]
Вы установили Y для отслеживания origin/X.
$ git branch -u origin/X Y
Branch 'Y' set up to track remote branch 'X' from 'origin'.
Вместо слияния с веткой upstream для обновления я рекомендую перебазировать. Это сделает вашу историю чище и упростит работу со слияниями. Запустите git pull --rebase. Вместо получения и слияния, Git будет получать и перезагружать. Это повторяет каждый ваш коммит поверх последней версии X.
A - B [origin/master]
\
C - D - G - H [origin/X]
\
E1 - F1 [Y]
Это похоже на то, как будто вы все время работали над последним X. Это позволяет избежать большого количества запутанных и ненужных «слияний обновлений».
Это также облегчает управление конфликтами слияния. Вместо того, чтобы иметь дело со всеми конфликтами слияния с X все сразу, вы можете делать их коммит за коммитом. Сначала вы имеете дело с конфликтами между E и X. Затем F и X. Разделение конфликтов на коммит позволяет легче увидеть, что конфликтует и почему.
Вы можете сделать это по умолчанию в вашем .gitconfig. К этому нужно привыкнуть.
[pull]
rebase = preserve
Независимо от того, объединяете ли вы или перебазируете, разрешение конфликта является одним и тем же базовым процессом. Разрешение конфликта в Git похоже на то, как коллега зовет вас, чтобы помочь с редактированием. Git объединит столько, сколько сможет, и поставит (git add) свою работу. Когда он сталкивается с чем-то, он не может с этим справиться, он редактирует файлы, чтобы показать, что он не может обработать с помощью маркеров конфликта , и оставляет эти биты неизменными и призывает человека (вас) это выяснить. Вы редактируете файлы, чтобы исправить их, ставите (git add) их и говорите Git перейти к следующему коммиту с git rebase --continue.
Или решите, что все пошло ужасно неправильно, и вы хотите начать с git rebase --abort.
Как только вы закончите работу со своим компонентом, объедините Y с X (или пусть Боб сделает это), удалите Y и начните новую ветвь с X для следующей функции.
Существует ветвь Х от мастера, которая в настоящее время используется другим техником для его собственных изменений. В ближайшие недели в ветви X будет много коммитов.
А теперь немного о том, почему долгоживущие и личные ветви - это кошмар, которого лучше всего избегать.
Ветвь объекта имеет четко определенную цель и четко определенную точку, когда они будут объединены. Напротив, личные ветви не имеют фокуса; они могут просто содержать то, над чем Боб работает сегодня. И у них нет конца. Они становятся долгоживущими ветвями.
Долгоживущие ветви - это кошмар, которого лучше всего избегать. По мере того, как они все больше расходятся с master, они будут обнаруживать все больше и больше несвязанных изменений и будут с меньшей и меньшей вероятностью когда-либо сливаться. Все больше и больше работы требуется для того, чтобы просто поддерживать их в актуальном состоянии с master (если они когда-либо беспокоятся), а все больше и больше приходится уходить на управление филиалами в филиалах.
Худшее - это долгоживущая личная ветвь. Он содержит все, над чем работал Боб. Кто знает, какие там изменения? Что они все должны делать? Они работают? Эти изменения хороши или плохи? Это именно то, что Боб решил сделать. Слияние - это прыжок веры в Боба.
Если возможно, закройте ветвь X как можно быстрее, избегайте личных ветвей и переходите к использованию кратковременных, четко определенных ветвей элементов .Хорошее управление филиалом достаточно сложно, как оно есть.Жизнь каждого будет гораздо лучше.