Я хотел бы перебазировать к конкретному коммиту, а не к HEAD другой ветки:

A --- B --- C          master
 \
  \-- D                topic

в

A --- B --- C          master
       \
        \-- D          topic

вместо того

A --- B --- C          master
             \
              \-- D    topic

Как я могу этого достичь?

Вы можете избежать использования параметра --onto, сделав временную ветвь для коммита, который вам нравится, и затем используйте rebase в его простой форме:

git branch temp master^
git checkout topic
git rebase temp
git branch -d temp

Вы даже можете принять прямой подход:

git checkout topic
git rebase <commitB>

Используйте опцию «на»:

git rebase --onto master^ D^ D

Комментарий jsz выше спас меня от тонны боли, поэтому вот пошаговый получатель, основанный на нем, который я использовал, чтобы перебазировать / переместить любой коммит поверх любого другого коммита:

1. Найдите предыдущую точку ветвления ветви, которую нужно перебазировать (переместить) - назовите ее старым родителем. В приведенном выше примере это A
2. Найдите коммит, поверх которого вы хотите переместить ветку - назовите его новым родителем. На экзамене это Б
3. Вы должны быть на своей ветке (той, которую вы перемещаете):
4. Примените ваш ребаз: git rebase --onto <new parent> <old parent>

В приведенном выше примере это так же просто, как:

   git checkout topic
   git rebase --onto B A

Тема Решение

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

git rebase --onto B master
git rebase --onto master~1 master
git rebase --onto B A
git rebase --onto B C
git rebase --onto B

Если topicне отмечено, вы просто добавляете topicкоманду (кроме последней) следующим образом:

git rebase --onto B master topic

В качестве альтернативы, проверьте ветку сначала с:

git checkout topic

Перебазировать любую строку коммитов в целевой коммит

Базовая форма команды, которая нам нужна, взята из документации:

git rebase --onto <Target> [<Upstream> [<Branch>]]

<Branch>не является обязательным, и все, что он делает, это проверяет ветвь, указанную перед выполнением остальной команды. Если вы уже отметили ветку, которую хотите перебазировать, вам это не нужно. Обратите внимание, что вы должны были указать <Upstream>, чтобы указать, <Branch>или git будет думать, что вы указываете<Upstream> .

<Target>это коммит, к которому мы прикрепим нашу строку коммитов. Предоставляя имя ветки, вы просто указываете коммит заголовка этой ветки. <Target>может быть любым коммитом, который не будет содержаться в строке коммитов, которые будут перемещены. Например:

A --- B --- C --- D         master
      \
       \-- X --- Y --- Z    feature

Чтобы переместить всю ветвь функции, вы не можете выбрать X, Y, Zили , featureкак<Target> так как те все коммиты внутри группы перемещения.

<Upstream>особенный, потому что это может означать две разные вещи. Если это коммит, который является предком извлеченной ветви, то он служит точкой вырезания. В этом примере я представил, это было бы ничего , что не C, Dили master. Все коммиты после, <Upstream>пока глава извлеченной ветки не будут перемещены.

Однако если if <Upstream>не является предком, то git выполняет резервное копирование цепочки из указанного коммита до тех пор, пока if не найдет общего предка с извлеченной ветвью (и не прекратит работу, если не может его найти). В нашем случае, <Upstream>из B, C, Dили masterбудет весь результат фиксации , Bвыступающим в качестве точки разреза. <Upstream>сама по себе является необязательной командой, и если она не указана, то git просматривает родителя извлеченной ветви, что эквивалентно вводу master.

Теперь, когда git выбрал коммиты, которые он будет вырезать и перемещать, он применяет их для того, чтобы <Target>пропустить все, которые уже применены к цели.

Интересные примеры и результаты

Используя эту отправную точку:

A --- B --- C --- D --- E         master
            \
             \-- X --- Y --- Z    feature

• git rebase --onto D A feature
  Будет ли применяться фиксаций B, C, X, Y, Zсовершить Dи в конечном итоге пропуск Bи Cпотому , что они уже были применены.

• git rebase --onto C X feature
  Будет применять коммиты Yи Zкоммитить C, эффективно удаляя коммитX

Более простое решение git rebase <SHA1 of B> topic. Это работает независимо от того, где вы HEADнаходитесь.

Мы можем подтвердить это поведение из git rebase doc

<upstream>Восходящая ветка для сравнения. Может быть любой допустимый коммит , а не просто существующее имя ветки. По умолчанию настроен восходящий поток для текущей ветви.

git rebase <SHA1 of B> <SHA1 of topic>

Это также будет работать, но rebase не будет Topicуказывать на новую созданную ветку и HEADбудет в отдельном состоянии. Отсюда вы должны вручную удалить старую Topicветку и создать новую ссылку на новую ветку, созданную rebase.

Я использовал смесь решений, описанных выше:

$ git branch temp <specific sha1>
$ git rebase --onto temp master topic
$ git branch -d temp

Мне было намного легче читать и понимать. Принятое решение привело меня к конфликту слияний (слишком ленив, чтобы исправить вручную):

$ git rebase temp
First, rewinding head to replay your work on top of it...
Applying: <git comment>
Using index info to reconstruct a base tree...
M       pom.xml
.git/rebase-apply/patch:10: trailing whitespace.
    <some code>
.git/rebase-apply/patch:17: trailing whitespace.
        <some other code>
warning: 2 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
error: Failed to merge in the changes.
Patch failed at 0001 <git comment>
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Поскольку перебазирование является настолько фундаментальным, вот расширение ответа Нестора Миляева . Объединение комментариев jsz и Simon South из ответа Адама Димитрука дает команду, которая работает на topicветви независимо от того, ветвится ли она из masterкоммита ветви Aили C:

git checkout topic
git rebase --onto <commit-B> <pre-rebase-A-or-post-rebase-C-or-base-branch-name>

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

Примеры:

# if topic branches from master commit A:
git checkout topic
git rebase --onto <commit-B> <commit-A>

# if topic branches from master commit C:
git checkout topic
git rebase --onto <commit-B> <commit-C>

# regardless of whether topic branches from master commit A or C:
git checkout topic
git rebase --onto <commit-B> master

Поэтому последняя команда - это та, которую я обычно использую.

Есть другой способ сделать это, или если вы хотите вернуться к более чем одному коммиту.

Вот пример возврата к nколичеству коммитов:

git branch topic master~n

Ради этого вопроса это также можно сделать:

git branch topic master~1

Команда отлично работает на git version 2.7.4. Не проверял ни на одной другой версии.