¿Cómo uso 'git rebase -i' para volver a establecer la base de todos los cambios en una rama?

Question

He aquí un ejemplo:

>git status 
# On branch master 
nothing to commit (working directory clean) 
>git checkout -b test-branch 
>vi test.c 
>git add test.c 
>git commit -m "modified test.c" 
>vi README 
>git add README 
>git commit -m "modified README" 

Ahora quiero hacer un 'git rebase -i' que me permita rebase todas las confirmaciones de esta rama. ¿Hay algo como 'git rebase -i HEAD~MASTER' o similar? Me imagino que podría hacer 'git rebase -i HEAD~2', pero realmente no quiero tener que contar cuántas confirmaciones se han realizado. También podría hacer 'git rebase -i sha1' pero no quiero peinarlo a través del registro de git para encontrar el primer commit sha1. ¿Algunas ideas?

Answer 1

¿Has probado: git rebase -i master?

Answer 2

Use gitk (* nix), o gitx (OS X) o similar en otras plataformas, y observe la confirmación que fue la raíz de su rama. A continuación, ejecute:

git rebase -i <the SHA hash of the root commit> 

Por ejemplo, tengo un repositorio que inspeccioné usando gitx:

gitx screencap http://img.skitch.com/20081213-mq7qpp5nhceksdhfx14rerjgyx.jpg

Ahora que sé que el hash de la raíz que se puede ejecutar esto:

git rebase -i 38965ed29d89a4136e47b688ca10b522b6bc335f 

Y mi editor aparece con esto y puedo reorganizar/aplastar/lo que quiera.

pick 50b2cff File 1 changes. 
pick 345df08 File 2 changes. 
pick 9894931 File 3 changes. 
pick 9a62b92 File 4 changes. 
pick 640b1f8 File 5 changes. 
pick 1c437f7 File 6 changes. 
pick b014597 File 7 changes. 
pick b1f52bc File 8 changes. 
pick 40ae0fc File 9 changes. 

# Rebase 38965ed..40ae0fc onto 38965ed 
# 
# Commands: 
# pick = use commit 
# edit = use commit, but stop for amending 
# squash = use commit, but meld into previous commit 
# 
# If you remove a line here THAT COMMIT WILL BE LOST. 
# However, if you remove everything, the rebase will be aborted. 
# 

estoy seguro de que hay alguna forma mágica para convencer a git para averiguar la raíz del árbol de forma automática, pero no sé lo que es.

EDIT: Esa magia es la siguiente:

git log master..other_feature | cat 

que le mostrará todas las confirmaciones en esa rama, y ​​las tuberías a gato se desactivará el localizador de manera que vea la primera inmediatamente envían.

EDIT: la combinación de lo anterior da una solución totalmente automatizada:

git rebase -i `git log master..other_feature --pretty=format:"%h" | tail -n 1`~ 

Answer 3

Ok, estoy Asumiendo la rama se llama "característica" y se ramificado de "maestro".

Hay este pequeño comando git llamado combinación-base. Se necesitan dos commits y te da el primer ancestro común de ambos. Así que ...

git merge-base feature master 

... le dará el primer antepasado común de estas dos confirmaciones. Adivinar lo que sucede cuando se pasa de que se comprometan a git rebase -i, como ...

git rebase -i `git merge-base feature master` 

interactivo rebase desde el primer antepasado común de ambos principal y característica de la rama. ¡Beneficio! ;)

Answer 4

Una solución general (si no conoce el nombre de la rama aguas arriba) es:

git rebase -i @{upstream} 

Tenga en cuenta que si su corriente arriba (probablemente una rama de seguimiento) ha actualizado desde la última vez rebasada, tirarás nuevas confirmaciones de la corriente ascendente.Si no desea obtener nuevas confirmaciones, use

git rebase -i `git merge-base --all HEAD @{upstream}` 

pero eso es un poco engorroso.

Answer 5

git rebase -i --onto @{u}... @{u} 

rebase interactivo a partir del punto de fusión única de la cabeza y su aguas arriba incluyendo todos los envíos en la cabeza de que no están en su contra la corriente.

En otras palabras, exactamente lo que quiere.

Answer 6

Desde Git v1.7.10, puede simplemente ejecutar git rebase sin argumentos, y encontrará el punto de horquilla y rebase sus cambios locales en la rama ascendente.

Debe haber configurado la rama ascendente para que esto funcione (es decir, git pull sin argumento debería funcionar).

Para más detalles, consulte la documentación de git rebase:

Si no se especifica, el sentido ascendente configurados en opciones branch..remote y branch..merge será utilizado (ver git-config [ 1] para más detalles) y se asume la opción --fork-point. Si no está actualmente en ninguna rama o si la rama actual no tiene configurada en sentido ascendente, la rebase abortará.

Answer 7

El problema con todas las soluciones proporcionadas es que no permiten volver a establecer la base de datos desde la primera confirmación. Si el hash primero comprometerse es XYZ y lo hace:

git rebase -i XYZ 

Sólo se rebase a partir de la segunda comprometerse.

Si desea reajustar desde el primer comprometerse haces:

git rebase -i --root 

Answer 8

El problema con el cambio de base de una rama diferente

El problema con git rebase -i master es que es posible que tenga conflictos de combinación que se no necesariamente desea tratar con esto en este momento, o puede solucionar un conflicto en una confirmación, solo para corregirlo nuevamente en otra confirmación durante el transcurso de la rebase.

El problema con el cambio de base de un conocido cometer

Todo el problema aquí es que usted tiene que saber cuales confirmar tiene que referirse, ya sea por su SHA, o la cabeza ~ x, etc. Esto es solo una pequeña molestia pero es una molestia.

La mejor manera

Si por el contrario quiere reajustar todos los compromete en su rama actual, ya que la más reciente cometer compartía con su rama padre, usted puede agregar la siguiente alias.gitconfig:

rbi = !sh -c \"git rebase -i `git merge-base $1 HEAD`\" - 

Uso

git rbi parentBranch 

Cómo funciona

Este alias es solamente un guión, es decir, utilizando un argumento que se refiere a la rama principal. Ese argumento se pasa al git merge-base para determinar la confirmación compartida más reciente entre esa rama y la rama actual.