El escondite solo realizó cambios en git: ¿es posible?

¿Hay alguna forma en que pueda esconder solo mis cambios por etapas? El escenario con el que estoy teniendo problemas es cuando he trabajado en varios errores en un momento dado y tengo varios cambios sin clasificar. Me gustaría poder organizar estos archivos individualmente, crear mis archivos .patch y guardarlos hasta que se apruebe el código. De esta manera, cuando se aprueba, puedo esconder toda mi sesión (actual), reventar ese error y presionar el código.

¿Voy por esto de la manera incorrecta? ¿Estoy malinterpretando cómo git puede funcionar de otras maneras para simplificar mi proceso?

Sí, es posible con DOUBLE STASH

1. Organice todos sus archivos que necesita guardar.
2. Ejecutar git stash --keep-index. Este comando creará un alijo con TODOS sus cambios (en etapas y sin etapas ), pero dejará los cambios en etapas en su directorio de trabajo (todavía en estado).
3. correr git stash push -m "good stash"
4. Ahora su SOLO"good stash" tiene archivos organizados .

Ahora, si necesita archivos sin clasificar antes de la ocultación, simplemente aplique la primera ocultación ( la creada con--keep-index ) y ahora puede eliminar los archivos que guardó "good stash".

Disfrutar

Con el último git puedes usar la --patchopción

git stash push --patch  

git stash save --patch   # for older git versions

Y git le pedirá cada cambio en sus archivos para agregar o no al escondite.
Solo respondes yon

UPD
Alias ​​para DOBLE STASH :

git config --global alias.stash-staged '!bash -c "git stash --keep-index; git stash push -m "staged" --keep-index; git stash pop stash@{1}"'

Ahora puede organizar sus archivos y luego ejecutarlos git stash-staged.
Como resultado, sus archivos almacenados se guardarán en el alijo .

Si no desea mantener los archivos almacenados y desea moverlos a un alijo. Luego puede agregar otro alias y ejecutar git move-staged:

git config --global alias.move-staged '!bash -c "git stash-staged;git commit -m "temp"; git stash; git reset --hard HEAD^; git stash pop"'

Hice un guión que oculta solo lo que está escenificado actualmente y deja todo lo demás. Esto es increíble cuando empiezo a hacer muchos cambios no relacionados. Simplemente ponga en escena lo que no está relacionado con la confirmación deseada y oculte solo eso.

(Gracias a Bartłomiej por el punto de partida)

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}

TL; DR Solo agregue -- $(git diff --staged --name-only)para su <pathspec>parámetro git

Aquí hay una línea simple:

git stash -- $(git diff --staged --name-only)

Y para agregar un mensaje simplemente:

git stash push -m "My work in progress" -- $(git diff --staged --name-only)

Probado en v2.17.1 y v2.21.0.windows.1

Limitaciones:

• Tenga en cuenta que esto esconderá todo, si no tiene archivos almacenados.
• Además, si tiene un archivo que está parcialmente en etapas (es decir, solo algunas líneas cambiadas, están puestas en escena, mientras que otras líneas cambiadas no lo están), entonces el archivo completo se guardará (incluidas las líneas sin etapas).

Para lograr lo mismo ...

1. Organice solo los archivos en los que desea trabajar.
2. git commit -m 'temp'
3. git add .
4. git stash
5. git reset HEAD~1

Auge. Los archivos que no quieres están guardados. Los archivos que desea están listos para usted.

En este escenario, prefiero crear nuevas sucursales para cada problema. Uso un prefijo temp /, así que sé que puedo eliminar estas ramas más tarde.

git checkout -b temp/bug1

Organice los archivos que corrigen el bug1 y confírmelos.

git checkout -b temp/bug2

Luego, puede seleccionar los commits de las ramas respectivas según sea necesario y enviar una solicitud de extracción.

¿Por qué no confirma el cambio para un error determinado y crea un parche a partir de ese compromiso y su predecesor?

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

Luego, para crear los parches apropiados, use git format-patch:

git format-patch HEAD^^

Esto creará dos archivos: 0001-fix-bug-123.patchy0002-fix-bug-321.patch

O puede crear ramas separadas para cada error, de modo que pueda fusionar o volver a crear correcciones de errores individualmente, o incluso eliminarlas, si no funcionan.

git stash --keep-index es una buena solución ... excepto que no funcionó correctamente en las rutas que se han eliminado, lo que se ha solucionado en Git 2.23 (Q3 2019)

Ver commit b932f6a (16 de julio de 2019) por Thomas Gummerer ( tgummerer) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit f8aee85 , 25 jul 2019)}

stash: arregla el manejo de archivos eliminados con --keep-index

git stash push --keep-index se supone que mantiene todos los cambios que se han agregado al índice, tanto en el índice como en el disco.

Actualmente, esto no se comporta correctamente cuando se elimina un archivo del índice.
En lugar de mantenerlo eliminado en el disco, ** - keep-index actualmente restaura el archivo. **

Solucione ese comportamiento usando ' git checkout' en modo sin superposición que puede restaurar fielmente el índice y el árbol de trabajo.
Esto también simplifica el código.

Tenga en cuenta que esto sobrescribirá los archivos sin seguimiento si el archivo sin seguimiento tiene el mismo nombre que un archivo que se ha eliminado en el índice.

Esconder solo el índice (cambios por etapas) en Git es más difícil de lo que debería ser. Encontré que la respuesta de @Joe funciona bien, y convertí una pequeña variación en este alias:

stash-index = "!f() { \
  git stash push --quiet --keep-index -m \"temp for stash-index\" && \
  git stash push \"$@\" && \
  git stash pop --quiet stash@{1} && \
  git stash show -p | git apply -R; }; f"

Empuja tanto la puesta en escena y cambios unstaged en un escondite temporal, dejando el cambio por etapas solos. Luego empuja los cambios por etapas en el alijo, que es el alijo que queremos mantener. Los argumentos pasados ​​al alias, como --message "whatever"se agregarán a este comando de ocultación. Finalmente, muestra el alijo temporal para restaurar el estado original y elimina el alijo temporal, y luego finalmente "elimina" los cambios escondidos del directorio de trabajo a través de una aplicación de parche inverso.

Para el problema opuesto de esconder solo los cambios no escalonados (alias stash-working), vea esta respuesta .

¿Es absolutamente necesario trabajar en varios errores a la vez? Y por "a la vez", quiero decir "tener archivos editados para múltiples errores al mismo tiempo". Porque a menos que lo necesite absolutamente, solo trabajaría en un error a la vez en su entorno. De esa manera, puede usar sucursales locales y rebase, lo cual me parece mucho más fácil que administrar un alijo / escenario complejo.

Digamos que master está en commit B. Ahora trabaje en el bug # 1.

git checkout -b bug1

Ahora estás en la rama bug1. Realice algunos cambios, confirme, espere la revisión del código. Esto es local, por lo que no está afectando a nadie más, y debería ser bastante fácil hacer un parche de git diffs.

A-B < master
   \
    C < bug1

Ahora estás trabajando en bug2. Ir volver a principal con git checkout master. Hacer una nueva rama, git checkout -b bug2. Haga cambios, comprométase, espere la revisión del código.

    D < bug2
   /
A-B < master
   \
    C < bug1

Supongamos que otra persona comete E&F en master mientras espera la revisión.

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

Cuando se aprueba su código, puede volverlo a crear en master con los siguientes pasos:

git checkout bug1
git rebase master
git checkout master
git merge bug1

Esto resultará en lo siguiente:

    D < bug2
   /
A-B-E-F-C' < master, bug1

Luego puede presionar, eliminar su rama local bug1, y listo. Un error a la vez en su espacio de trabajo, pero con el uso de ramas locales, su repositorio puede manejar múltiples errores. Y esto evita una etapa complicada de baile.

Responda a la pregunta de ctote en los comentarios:

Bueno, puedes volver a esconder cada error y solo trabajar con un error a la vez. Al menos eso te ahorra el problema de la puesta en escena. Pero después de haber intentado esto, personalmente lo encuentro problemático. Los escondites son un poco desordenados en un gráfico de registro de git. Y lo más importante, si arruinas algo, no puedes revertirlo. Si tiene un directorio de trabajo sucio y hace estallar un alijo, no puede "deshacer" ese pop. Es mucho más difícil arruinar los compromisos ya existentes.

Por lo tanto git rebase -i.

Cuando vuelve a crear una rama en otra, puede hacerlo de forma interactiva (el indicador -i). Cuando haces esto, tienes la opción de elegir lo que quieres hacer con cada confirmación. Pro Git es un libro increíble que también está en línea en formato HTML, y tiene una buena sección sobre rebase y aplastamiento:

http://git-scm.com/book/ch6-4.html

Robaré su ejemplo literalmente por conveniencia. Suponga que tiene el siguiente historial de confirmaciones y desea volver a crear y aplastar bug1 en master:

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

Esto es lo que verá cuando escriba git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, 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.
#

Para aplastar todos los commits de una rama en un solo commit, mantenga el primer commit como "pick" y reemplace todas las entradas posteriores "pick" con "squash" o simplemente "s". También tendrá la oportunidad de cambiar el mensaje de confirmación.

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

Así que sí, aplastar es un poco molesto, pero aún así lo recomendaría sobre el uso intensivo de los escondites.

De sus comentarios a la respuesta de Mike Monkiewicz, sugiero usar un modelo más simple: use ramas de desarrollo regulares, pero use la opción de squash de la combinación para obtener una confirmación única en su rama maestra:

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

La ventaja de este procedimiento es que puede usar el flujo de trabajo normal de git.

TL; DR ;git stash-staged

Después de crear un alias:

git config --global alias.stash-staged '!bash -c "git stash -- \$(git diff --staged --name-only)"'

Aquí git diffdevuelve la lista de --stagedarchivos --name-only
Y luego pasamos esta lista pathspeca git stashcommad.

De man git stash:

git stash [--] [<pathspec>...]

<pathspec>...
   The new stash entry records the modified states only for the files
   that match the pathspec. The index entries and working tree
   files are then rolled back to the state in HEAD only for these
   files, too, leaving files that do not match the pathspec intact.

Para podar un cambio accidental, especialmente la eliminación de varios archivos, haga lo siguiente:

git add <stuff to keep> && git stash --keep-index && git stash drop

en otras palabras, esconde la basura y tírala con el alijo por completo.

Probado en git versión 2.17.1