¿Cómo manejarlo cuando un commit en progreso de repente parece depender de otro que aún no está allí?

No tengo experiencia con Git, pero hago todo lo posible para acostumbrarme, y hasta ahora solo lo estoy usando para proyectos en los que trabajo solo.

Cuando codifico, hay un enfoque de arriba hacia abajo naturalmente (ya que no puedo saber el futuro), y hay un tema recurrente:

Yo hago un poco de trabajo
Descubro que para convertir mi trabajo en algo "comunicable" necesito hacer otro trabajo.
El otro trabajo merece su propio compromiso.

Por algo comunicable me refiero a algo que se compila o algo que no es un desastre total.
Y por algo que merece su propio compromiso, me refiero a que aprendí que los compromisos deberían hacer una sola cosa.

La forma en que lo resuelvo es engorrosa. Si el otro trabajo está en otro archivo, hago una nueva rama, me comprometo allí y me fusiono. Si el trabajo está en el mismo archivo ... ugh ... Hago una copia local y restablezco el archivo a su estado en HEAD, hago el commit necesario y luego empiezo a restaurar mi trabajo desde la copia. ¿Cómo debería manejar eso? No me imagino que este sea el camino, ¿verdad? No lo supongo porque debe ser algo frecuente para todos (que al menos tampoco conocen el futuro). ¿O tal vez parece que mi flujo de trabajo puede ser defectuoso?

Hay múltiples formas de resolver esto.

Si desea hacer los cambios para la primera confirmación sin interferir con sus cambios actuales, puede usar git stash. Esto eliminará todos los cambios abiertos, lo que le permitirá restaurarlos más tarde. Use git statuspara ver que ya no están presentes. Ahora cree la primera confirmación como está acostumbrado. A continuación, puede usar git stash poppara restaurar sus cambios originales y crear la segunda confirmación, haciendo su trabajo principal.

Otra forma sería hacer todos los cambios necesarios y luego crear dos confirmaciones, ambas conteniendo una parte de su trabajo. Para hacerlo, puede usar el índice (también conocido como el área de ensayo) proporcionado por git. Esta es un área especial que puede usar para preparar confirmaciones. Suponiendo que ha cambiado varios archivos, puede agregar cada uno de ellos al índice usando git add. Al hacer git commitsolo se comprometerán los archivos agregados al índice. git statusle mostrará qué partes de sus cambios se comprometerán y cuáles no. Por ejemplo, se verá así después de cambiar los archivos a.txt, b.txt y c.txt y luego hacer git add a.txt:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   a.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   b.txt
        modified:   c.txt

Cuando lo haga git commiten este estado, solo se agregarán a su confirmación los cambios en a.txt.

Además, puede revisar los cambios exactos que se van a confirmar utilizando git diff --cached, lo que le mostrará una diferencia de todos los cambios que se van a confirmar.

Si un archivo contiene cambios para ambas confirmaciones, también puede agregar solo partes de él al índice utilizando "git add --patch b.txt". git le proporcionará un modo interactivo que le solicita cada cambio en el archivo dado si debe agregarse al índice. Esto podría ser más difícil si tiene cambios en las líneas una al lado de la otra, que deben dividirse en las dos confirmaciones, sin embargo, también hay formas de resolverlo.

Si desea obtener más información sobre el área de preparación, puede leer esto: http://gitready.com/beginner/2009/01/18/the-staging-area.html

También es posible que desee leer más sobre la adición interactiva aquí: http://nuclearsquid.com/writings/git-add/

Si usa una GUI para Git, como SourceTree de Atlassian, o git guipuede confirmar partes de archivos y dejar otras partes sin confirmar. De hecho, puede confirmar líneas de código individuales.

Hago esto con frecuencia cuando me caigo en las madrigueras de los conejos como usted describe. Esta es una excelente manera de hacer ese commit o commit sensible como precursor del commit principal.

Puede hacerlo desde la línea de comandos, pero es un poco torpe.

Cuando puede comprometerse a nivel de parche Git y líneas individuales, no necesita crear nuevas ramas, esconder, confirmar, esconder y fusionar. Solo sigue trabajando y no rompas el flujo. Tienes algo bueno en marcha.