¿guardar automáticamente los cambios de guardar / pop en git rebase?

Editar: A partir de la versión 1.8.4 de Git, pero con un importante error lateral corregido en la versión 2.0.1 de Git, git rebase ahora tiene --autostash. Puede configurar git rebase para usar --autostash también de forma predeterminada, con git config --global rebase.autoStash true. Tenga en cuenta la siguiente frase de la documentación :

Sin embargo, use con cuidado: el alijo final la aplicación después de un rebase exitoso podría resultar en no trivial conflicto.

(Todavía prefiero solo hacer commits.)

TL; DR respuesta: solo haz un commit (luego deshazlo más tarde)

Puede ayudarle a darse cuenta de que git stash es realmente solo git commit (en una forma más complicada, que confirma el índice primero, luego el árbol de trabajo: cuando aplica un alijo, puede mantener la separación de índice y árbol de trabajo, o combinarlos en solo un cambio de árbol de trabajo).

Lo que hace especial a un stash es que las confirmaciones que hace-las dos o, con -u o -a, incluso tres confirmaciones-se hacen de una forma inusual (como una fusión commit que no es realmente una fusión) y no se coloca en ninguna rama (en su lugar, la referencia especial refs/stash se utiliza para retenerlos y encontrarlos).

Dado que no están en una rama, rebase no los toca, y en su flujo de trabajo, es el git stash pop que trae los cambios del árbol de trabajo a su nuevo árbol de trabajo. Sin embargo, si haces tu propio commit (normal), en una rama, y rebases e incluyes ese commit, este commit normal será rebases junto con cualquier otro. Vamos a llegar a un último problema en un momento; por ahora, vamos a dibujar esto, como una serie de commits que hacen (o no) se vuelven a basar:

... do some work ...
... make some commits ...
... more work ...
... do something that causes upstream/master to update, such as git fetch upstream
$ git stash

En este punto, esto es lo que tienes:{[101]]}

... - o - * - A - B - C     <-- HEAD=master
           \          |\
            \         i-w   <-- stash
             \
              @-@-@         <-- upstream/master

Aquí, A, B, y C son tus commits (asumiré que has hecho 3), todos en la rama master. El i-w hanging off commit C es tu stash, que no está en la rama, pero sigue siendo un two-commit "git stash bag" y en realidad está adjunto a tu último commit (C). El @ se compromete (podría be just one) son los nuevos commits de upstream.

(Si has hecho no commits, tu stash-bag cuelga de commit *, y tu rama actual apunta a commit *, de modo que git rebase no tiene más trabajo que hacer que mover tu puntero de rama actual hacia adelante. Todo funciona igual, en este caso, pero asumiré que hay algunas confirmaciones.)

Ahora corres git rebase upstream/master. Esto copia tus commits a nuevos commits, con nuevos IDs y nuevos IDS padre, para que se sitúen encima del last @. El stash-bag no se mueve, por lo que el resultado se ve así:

... - o - * - A - B - C     [abandoned, except for the stash]
           \          |\
            \         i-w   <-- stash
             \
              @-@-@         <-- upstream/master
                   \
                    A'-B'-C'   <-- HEAD=master

Ahora se usa git stash pop, que restaura el material i/w a medida que cambia el árbol de trabajo, borrando la etiqueta stash (más precisamente, explotándola para que stash@{1}, si existe, sea ahora stash, y así sucesivamente). Eso libera las últimas referencias a la cadena A - B - C original, y significa que tampoco necesitamos el bit i-w, lo que nos permite volver a dibujar esto como el mucho más simple:

... - @            <-- upstream/master
       \
        A'-B'-C'   <-- HEAD=master plus work tree changes

Ahora vamos a dibujar lo que sucede si, en lugar de git stash save, solo tienes que hacer un git commit -a (o git add y git commit sin-a) para crear una confirmación real D. Comienza con:

... - o-*-A-B-C-D   <-- HEAD=master
         \
          @-@-@     <-- upstream/master

Ahora tú git rebase upstream/master, que copia A a través de D para colocarlos al final de la última @, y tienes esto:

... - o-*-@-@-@     <-- upstream/master
               \
                A'-B'-C'-D'   <-- HEAD=master

El único problema es que tiene esta confirmación adicional no deseada D (bueno, D' ahora), en lugar de cambios en el árbol de trabajo no comprometidos. Pero esto se deshace trivialmente con git reset retroceder un commit. Podemos utilizar un --mixed reset-el valor predeterminado-para volver a configurar el índice (área de preparación) también, para "des-añadir" todos los archivos, o si desea que se queden git add-ed, un --soft reset. (Ninguno afecta al gráfico de confirmación resultante, solo el estado del índice es diferente.)

git reset --mixed HEAD^   # or leave out `--mixed` since it's the default

Esto es lo que parece:

... - o-*-@-@-@     <-- upstream/master
               \
                A'-B'-C'      <-- HEAD=master
                        \
                         D'   [abandoned]

Puedes pensar que esto es ineficiente, pero cuando usas git stash en realidad estás haciendo al menos dos commits, que luego abandonas más tarde cuando git stash pop ellos. La verdadera diferencia es que al hacer confirmaciones temporales, no para publicación, obtienes esas automáticamente rebasadas.

No tengas miedo de confirmaciones temporales

Hay una regla general con git: hacer lotes de confirmaciones temporales, para guardar tu trabajo sobre la marcha. Siempre puedes cambiarlos de base más tarde. Es decir, en lugar de esto:

... - * - A - B - C   <-- mybranch

Donde A, B, and C are perfect and final commits at top commit * (from someone else or earlier published stuff), make esto:

... - * - a1 - a2 - b1 - a3 - b2 - a4 - b3 - c1 - b4 - c2 - c3

Donde a1 es una puñalada inicial en A, a2 corrige un error en a1, b1 es un intento inicial de hacer que b funcione, a3 es darse cuenta de que b1 requiere A ser diferente después de todo, b2 corrige un error en b1, a4 corrige un error en el cambio de a3 a a2, y b3 es lo que b1 debería haber hecho; entonces c1 es un intento inicial de C, b4 es otra solución a b1, c2 es un refinamiento, y así sucesivamente.

Digamos que después de c3 crees que está casi listo. Ahora ejecuta git rebase -i origin/master o lo que sea, baraja las líneas pick para obtener a1 a través de a4 en orden, b1 a través de b4 en orden, y c1 a través de c3 en orden, y deja que la rebase se ejecute. Luego arreglas cualquier conflicto y te aseguras de que las cosas siguen siendo correctas, luego ejecutas otro git rebase -i para colapsar las cuatro versiones a en A, y así sucesivamente.

Cuando hayas terminado, parece como si hubieras creado un perfecto A la primera vez (o tal vez con a4 o algún otro dependiendo de qué confirmaciones mantengas y cuáles sueltes y si vuelves a establecer marcas de tiempo en las cosas). Otras personas pueden no querer o necesitar ver tu trabajo intermedio-aunque puedes conservarlo, no combinando commits, si eso es útil. Mientras tanto, nunca necesitas tener cosas no comprometidas que tengas que rebase, porque solo tienes confirmaciones de cosas parciales.

Ayuda a dar estos nombres de confirmaciones, en la línea texto de confirmación, que guiará su trabajo de rebase posterior:

git commit -m 'temp commit: work to enable frabulator, incomplete'

Y así sucesivamente.