Me gustaría cambiar la base a un commit específico, no a un HEAD de la otra rama:

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

a

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

en vez de

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

¿Cómo puedo lograr eso?

Puede evitar el uso del parámetro --onto haciendo una rama temporal en el commit que desee y luego use rebase en su forma simple:

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

Incluso puedes tomar un enfoque directo:

git checkout topic
git rebase <commitB>

Use la opción "sobre":

git rebase --onto master^ D^ D

El comentario de jsz anterior me ahorró un montón de dolor, así que aquí hay una receta paso a paso basada en ella que he estado usando para cambiar la base / mover cualquier confirmación encima de cualquier otra confirmación:

1. Encuentre un punto de ramificación anterior de la rama que se va a volver a armar (mover): llámelo padre antiguo. En el ejemplo anterior, eso es A
2. Busque commit sobre el cual desea mover la rama, llámelo nuevo padre. En el examen eso es B
3. Debes estar en tu rama (la que mueves):
4. Aplica tu rebase: git rebase --onto <new parent> <old parent>

En el ejemplo anterior, es tan simple como:

   git checkout topic
   git rebase --onto B A

Solución de tema

El comando correcto para responder la pregunta publicada podría ser cualquiera de los siguientes (suponiendo que la rama topicya esté desprotegida):

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

Si topicno está desprotegido, simplemente agregue topicel comando (excepto el último) así:

git rebase --onto B master topic

Alternativamente, revise la sucursal primero con:

git checkout topic

Rebase cualquier cadena de confirmaciones a una confirmación de destino

La forma básica del comando que necesitamos, basada en la documentación, es:

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

<Branch>es opcional y todo lo que hace es verificar la rama especificada antes de ejecutar el resto del comando. Si ya ha desprotegido la rama que desea cambiar, entonces no necesita esto. Tenga en cuenta que debe haber especificado <Upstream>para especificar <Branch>o git pensará que está especificando <Upstream>.

<Target>es la confirmación a la que adjuntaremos nuestra cadena de confirmaciones. Al proporcionar un nombre de sucursal, simplemente está especificando la confirmación principal de esa rama. <Target>puede ser cualquier confirmación que no se incluirá en la cadena de confirmaciones que se mueven. Por ejemplo:

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

Para mover toda la rama de la característica, no se puede seleccionar X, Y, Zo featurecomo el <Target>ya que los todos son commits dentro del grupo que está siendo movido.

<Upstream>es especial porque puede significar dos cosas diferentes. Si se trata de una confirmación que es un antepasado de la rama desprotegida, entonces sirve como punto de corte. En el ejemplo que he proporcionado, esto podría ser cualquier cosa que no es C, Do master. Todos los commits posteriores <Upstream>hasta el encabezado de la rama desprotegida son los que se moverán.

Sin embargo, si <Upstream>no es un ancestro, entonces git realiza una copia de seguridad de la cadena desde el commit especificado hasta que encuentre un ancestro común con la rama desprotegida (y aborta si no puede encontrar uno). En nuestro caso, una <Upstream>de B, C, D, o masterse traducirán en cometer Bservir como punto de corte. <Upstream>es en sí mismo un comando opcional y si no se especifica, entonces git mira al padre de la rama desprotegida que es el equivalente de ingresar master.

Ahora que git ha seleccionado las confirmaciones que cortará y moverá, las aplicará para <Target>omitir las que ya se hayan aplicado al objetivo.

Ejemplos y resultados interesantes

Usando este punto de partida:

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

• git rebase --onto D A feature
  Se aplicará compromete B, C, X, Y, Zpara cometer Dy terminan saltando By Cdebido a que ya se han aplicado.

• git rebase --onto C X feature
  Aplicará commits Yy Zcommit C, eliminando efectivamente commitX

Una solución más simple es git rebase <SHA1 of B> topic. Esto funciona independientemente de dónde HEADesté.

Podemos confirmar este comportamiento desde git rebase doc

<upstream>Rama aguas arriba para comparar. Puede ser cualquier confirmación válida , no solo un nombre de sucursal existente. El valor predeterminado es el ascendente configurado para la rama actual.

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

Esto también funcionará, pero el rebase no hará referencia Topica una nueva rama así creada y HEADestará en estado separado. Entonces, desde aquí, debe eliminar manualmente la antigua Topicy crear una nueva referencia de rama en la nueva rama creada por rebase.

He usado una mezcla de soluciones descritas anteriormente:

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

Me resultó mucho más fácil de leer y entender. La solución aceptada me llevó a un conflicto de fusión (demasiado flojo para arreglarlo a mano):

$ 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".

Dado que el rebase es tan fundamental, aquí hay una expansión de la respuesta de Nestor Milyaev . La combinación de los comentarios de jsz y Simon South de la respuesta de Adam Dymitruk produce este comando que funciona en la topicrama independientemente de si se ramifica desde el mastercommit de la rama Ao C:

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

Tenga en cuenta que se requiere el último argumento (de lo contrario, rebobina su rama para confirmar B).

Ejemplos:

# 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

Entonces, el último comando es el que normalmente uso.

Hay otra forma de hacerlo o si desea volver a más de un solo commit.

Aquí hay un ejemplo para volver a n número de confirmaciones:

git branch topic master~n

En aras de esta pregunta, esto también se puede hacer:

git branch topic master~1

El comando funciona perfectamente git version 2.7.4. No lo he probado en ninguna otra versión.