Как мне управлять слиянием и перебазированием в git? - PullRequest
3 голосов
/ 02 декабря 2010

Я понимаю цель перебазирования.Это имеет смысл для меня.По сути, у меня есть ветвь функций, над которой я работаю, и я готов поместить ее в ветку master. Я бы сделал ребазу, чтобы объединить все мои коммиты в один чистый, чтобы он легко интегрировался в master без всякого беспорядка.история.Правильно?

Вот что мы делаем.

  1. Создание ветви компонента
  2. Добавление группы коммитов при построении функции
  3. Периодически объединяйте основную ветку с веткой функции (чтобы избежатьмучительное слияние по дороге)
  4. Когда все будет сделано, объединить ветвь объектов с мастером

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

Какой правильный рабочий процесс здесь?Где в игру вступают следующие запятые:

  • git rebase -i Head ^ #
  • мастер git rebase
  • мастер git merge
  • git-rerere
  • git reset --hard HEAD ^

Ответы [ 4 ]

5 голосов
/ 02 декабря 2010

Вы должны слиться с мастером только один раз, в конце жизни ветки.Идея ветки функции / темы заключается в том, что она содержит только изменения, относящиеся к этой функции;вы теряете это, когда вы постоянно сливаетесь с мастером.(Вы можете прочитать, что Джунио Хамано, сопровождающий git, говорит о ветвях .)

Вы можете выполнить «практическое» слияние, которое вы выбросите, и используйте git-rerere дляGit автоматически записывает ваши разрешения слияния, чтобы их можно было использовать повторно, когда вы действительно готовы к слиянию.См. http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html для справки и учебника.Это действительно круто, потому что это позволяет вам выполнять работу слияния, не фиксируя ее где-либо явно, а затем возвращать эту работу «волшебным образом», когда вы действительно готовы создать слияние.Таким образом, вместо одного большого болезненного слияния в конце, вы можете выполнить несколько небольших, надеюсь, более простых, промежуточных «тренировочных» слияний по пути.Грубо говоря:

# Enable rerere
git config --global rerere.enabled 1
# Start a feature branch
git checkout -b feature
# Hack hack hack
git commit
git commit
# Practice merge
git merge master
# ...then throw the merge commit away, the work is saved by rerere
git reset --hard HEAD^
# Hack hack hack
git commit
# Really merge to master, reusing any saved work from rerere
git checkout master
git merge feature
git branch -d feature

См. Также http://progit.org/2010/03/08/rerere.html для другого урока.

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

Чтобы справиться с ситуацией, подобной той, в которой вы находитесь в данный момент, с ветвью темы (скажем, с именем feature), в которой есть ряд слияний от основного, смешанных с различными выполняющимися коммитами,Самый простой подход - сделать сжатое слияние для создания «объединенного» рабочего дерева, а затем создать новый коммит (или серию коммитов) для main.Например:

git checkout master
git merge --squash feature
git commit

Это создаст один коммит, представляющий состояние дерева в начале элемента, объединенного с мастером.

Конечно, вы также можете просто сделатьрегулярное слияние с master для этого изменения, оставляя грязную историю feature настоящего, и просто работать более аккуратно в будущем.например, просто

git checkout master
git merge feature

и двигаться дальше.

3 голосов
/ 02 декабря 2010

Если вы собираетесь сделать ребаз (что я и предлагаю), то никогда не сливайтесь с мастером. Рабочий процесс перебазирования основан на идее, что ветвь темы состоит из пути от мастера к новой функции и ничего больше. Когда мастер движется вперед, ваши изменения, приближающиеся к новой функции, перемещаются вместе с ней.

Когда вы наконец готовы внести изменения в мастер, у вас есть два основных варианта:

  1. Сделайте ребаз против мастера в последний раз, затем выполните обычное ускоренное слияние, которое по существу приводит все коммиты вашей ветви к мастеру один за другим. Это сохраняет более детальную историю, но если промежуточные коммиты сломали сборку, то вы можете предпочесть раздавить их. Интерактивная перебазировка (-i) может помочь организовать эти коммиты.

  2. Используйте merge --squash, чтобы сделать один коммит в master, который содержит все изменения ветви.

0 голосов
/ 02 декабря 2010

Я считаю, что короткий ответ:

используйте git merge --squash, если:

если у вас есть ветвь функций и вы работаете с другой веткой в ​​этой ветке, например, вы переключаетесь на функцию и периодически запускаете git merge master для объединения в ветку master. Или вы тянете или толкаете эту ветку к другим или к центральному репо, например, к github.

используйте git rebase, если:

, если у вас есть ветвь функции, которую вы не выдвигаете или не тянете к другим, и вы периодически не объединяете другую ветку, как описано выше

0 голосов
/ 02 декабря 2010

Если вы все равно собираетесь перебазировать ветку, просто перебазируйте всякий раз, когда вы хотите «объединить» изменения. Вам не нужно перебазировать + сквош, пока вы не будете готовы «слить» эту ветку в мастер.

...