Нужно ли выполнять коммит после ребазинга? - PullRequest
Новая
       10

Нужно ли выполнять коммит после ребазинга?

7 голосов
/ 22 апреля 2010

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

Ребаз автоматически сохраняется где-то в виде коммита?

Где живут эти модификации? Я не вижу ничего в gitk или git log --oneline.

(Тот же вопрос, когда я объединяю свою ветвь после перебазировки.)

Ответы [ 3 ]

8 голосов
/ 22 апреля 2010

Rebase перемещает коммиты поверх другой ветви.Если перемещенный коммит вызывает конфликт слияния, этот коммит изменяется, отражая разрешение слияния.

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

Слияние отличается, потому что это явное действие слияния расходящихся ветвей вместе.Никаких коммитов в каждой из веток не меняется.Разрешение конфликта отражается в коммите слияния.

5 голосов
/ 22 апреля 2010

Да, успешные перебазировки и слияния совершают коммиты. Они только не сделают фиксацию, поскольку существуют конфликты, которые необходимо разрешить, но затем результат ребазирования (или слияния) скажет вам, что это произошло, и как разрешить это.

Для перебазирования вам просто нужно разрешить конфликты в индексе, а затем git rebase --continue.

Для слияния вам необходимо сделать коммит (git commit), но тот факт, что это слияние будет запомнено, и вам будет предоставлено подходящее сообщение о коммите по умолчанию для редактирования.

2 голосов
/ 22 апреля 2010

В старые времена (2006, до 1.5.3 и его руководство пользователя ), git rebase было представлено так :

Особый случай вишневого сбора - это если вы хотите переместить целую ветку в более новый «базовый» коммит.
Это сделано git-rebase.
Вы указываете ветку для перемещения (по умолчанию HEAD) и куда ее перемещать (по умолчанию нет), и:

  • git cherry-picks каждый патч из этой ветки,
  • применяет его к цели,
  • и перемещает указатель refs/heads/<branch> на вновь созданные коммиты.

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

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

Предположим, вы смешали разработку двух функций в текущем HEAD, ветке под названием "dev". 

x-x-x-x  (master)
       \ 
        -f1a-f1b-f1c-f2a-f2b-f2c (dev, HEAD)

Вы хотите разделить их на "dev1" и "dev2". Предполагая, что HEAD является ответвлением от мастера, вы можете просмотреть 

git log master..HEAD

или просто получить необработанный список коммитов с помощью 

git rev-list master..HEAD

В любом случае, предположим, что вы выясняете список коммитов, которые вы хотите в dev1 и создаете эту ветку: 

git checkout -b dev1 master
for i in `cat commit_list`; do
    git-cherry-pick $i
done

        -f1a'-f1b'-f1c' (dev1, HEAD)
       /
x-x-x-x  (master)
       \ 
        -f1a-f1b-f1c-f2a-f2b-f2c (dev)

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

git checkout -b dev2 dev    # Create dev2 branch
git-rebase --onto master dev1   # Subreact dev1 and rebase

Это найдет все патчи, которые находятся в dev, а не в dev1, примените их поверх мастера и назовите результат dev2. 

        -f1a'-f1b'-f1c' (dev1, HEAD)
       /
x-x-x-x  (master)
       \ 
        -f2a-f2b-f2c (dev2, HEAD)
...