Как отправить патч другому разработчику и избежать конфликтов слияния?

Question

Как получить патч из коммита, чтобы отправить его другому разработчику? И как мне лучше избежать конфликта слияния с этим патчем при слиянии наших деревьев позже?

Если вы знаете, как, пожалуйста, объясните, как это сделать в выбранной вами VCS, такой как subversion, git, Mercurial, bzr или т. Д.

Answer 1

В git вы можете передать git-diff между двумя коммитами, как это:

git diff fa1afe1 deadbeef > patch.diff

Отправьте patch.diff разработчику и дайте ему git-apply его в его рабочее пространство следующим образом:

git apply patch.diff

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

git apply < git diff fa1afe1 deadbeef

Затем вы можете добавить и зафиксировать изменения в diff обычным способом .

---

Теперь вот интересная часть, когда вам нужно объединить патч обратно с основной веткой (которая является публичной). Рассмотрим следующее дерево ревизий, где C* - это примененный патч из C в основной ветке:

A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

Вы можете использовать git-rebase, чтобы обновить ветку темы (в данном примере с именем feature_foo), указав ее верхнюю ветку. Это означает, что вы вводите следующее:

git rebase master feature_foo

Git перестроит дерево ревизий следующим образом, а также сам патч:

A---B---C---D          master, public/master
             \
              E*---F*  feature_foo

Слияние с вышестоящей ветвью теперь будет простым быстрым слиянием. Также убедитесь, что новые коммиты E* и F* работают как предыдущие E и F соответственно.

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

Обратите внимание, что никогда не перебазирует публичную ветку , потому что команда переписывает git history, что вы не хотите делать в ветках, от которых зависят люди, и создаст беспорядок при слиянии с удаленными репозиториями , Также никогда не забывайте часто интегрировать , чтобы другие члены вашей команды могли принять участие в ваших изменениях.

Answer 2

В Subversion нет хорошего способа сделать это. Да, вы можете использовать svn diff + patch, но это будет только откладывать ваши проблемы до тех пор, пока вы не собираетесь объединяться, и к тому времени, скорее всего, вы забыли об этом.

В Subversion вы могли бы создать ветку, выполнить коммит на ветке и попросить получателя патча переключиться на ветку. Затем вы можете слить ветку обратно в ствол обычным способом.

Answer 3

Bzr обрабатывает отправку «директивы слияния», то есть отправляет патч для вас, чтобы другая сторона могла просто нажать «ОК», чтобы слить , и теперь меньше проблем с патчем / применением и т. Д.

просто: $ bzr send -o mycode.patch

Answer 4

В SVN вы можете просто внести изменения, а затем перед передачей направить вывод svn diff в файл как таковой

svn diff > mypatch.diff

затем вы можете отменить изменения и применить исправление позже, используя

patch -p0 -i mypatch.diff

Как всегда, не применяйте патчи вслепую к вашему коду и всегда сначала проверяйте их.

Вы также можете обнаружить, что патч сломает ваш исходный код, если исходные файлы изменились достаточно значительно с момента его установки.

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