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

Question

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

Если вы знаете, как это сделать, объясните, как это сделать в выбранной вами системе управления версиями, например 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

Затем вы можете добавить и < a href = "http://www.kernel.org/pub/software/scm/git/docs/git-commit.html" rel = "noreferrer"> commit изменения в 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

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

svn diff > mypatch.diff

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

patch -p0 -i mypatch.diff

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

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

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

Answer 3

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

только:$ bzr send -o mycode.patch

Answer 4

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

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