2016-12-21 9 views
0

У меня есть две ветки. branch1 имеет последние изменения, другой (branch2) содержит самые последние изменения, которые находятся на пульте дистанционного управления.git rebase <SHA1>, похоже, не сквош комет

Так что я делаю, это я получаю самый последний общий совершить так:

SHA=$(git merge-base branch1 branch2) 

тогда я бегу перебазироваться

git checkout branch1 
git rebase ${SHA} 

проблема, которую я имею, что это не представляется сжимать фиксации на ветке1. Должна ли она раздавить коммиты, и мой краткий обзор неправильный?

Когда вы используете rebase с интерактивной опцией, вы указываете, нужно ли раздавать коммит.

мне интересно, если возможно, мне нужно использовать какой-то вариант, как и с помощью команды Rebase

git rebase -s ${SHA} 

или, может быть,

git rebase --autosquash ${SHA} 
+0

Ребаза по умолчанию не заполняется. Может быть, вы ищете флаг -i, где вы можете редактировать список переадресации – frlan

ответ

2

она должна быть давя фиксаций и мой синопсис не так?

Нет, по умолчанию это не так.

Концептуально, rebasing похож на притворство ветви всегда на вершине другой фиксации. Например, здесь у нас есть ветвь признаков, которая устарела.

A - B - C - D - E [master] 
     \ 
      F - G - H [feature] 

Мы могли git merge master, но тогда будет неаккуратно слияние совершает. Вместо этого мы можем переписать feature, как если бы он всегда находился на кончике «хозяина».

  • git checkout feature
  • git rebase master

Теперь у нас есть ...

    F1 - G1 - H1 [feature] 
       /
A - B - C - D - E [master] 
     \ 
      F - G - H 

Обратите внимание, что старая ветвь все еще там, в конечном итоге будет очищен.


Вместо этого вы ищете git merge --squash.

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

Вместо этого я бы рекомендовал «пузыри функций». Восстановите ветвь, как указано выше, затем git merge --no-ff (это заставляет Git сливаться, а не перемотка вперед). Это приводит к ...

    F1 - G1 - H1 
       /   \ 
A - B - C - D - E ------------ I [master] 

Вы получаете линейную историю (git log покажет I, H1, G1, F1, E, D, ...), вы сохраняете подробную информацию о фиксации, что F1, G1 и H1 связаны, и сообщение фиксации I может использоваться для описания того, что было в ветви.

+0

? Ну, должен быть способ автоматически сквош всех коммитов после того, как SHA предоставили ....? Мне не нужно делать это интерактивно, верно? –

+0

@AlexanderMills Как я уже сказал, 'git merge --squash'. Также, как я уже сказал, я сам не использую сквош и не поощряю его, поэтому я не могу сказать больше об этом. – Schwern

+0

ОК, но git merge --squash в каком контексте? Кажется, это другой контекст, чем тот, который в вопросе. и если да, добавьте любое объяснение, которое вы можете собрать. –