¿Cómo manejarlo cuando una confirmación en curso parece depender repentinamente de otra que aún no existe?

13

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

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

Trabajo un poco.
Descubrí que para convertir mi trabajo en algo "comprometible", necesito hacer otro trabajo.
El otro trabajo merece su propio compromiso.

Por algo comprometible me refiero a algo que 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 engorroso. 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 la confirmación necesaria y luego comienzo a restaurar mi trabajo desde la copia. ¿Cómo debo manejar eso realmente? No me imagino que este sea el camino, ¿verdad? No lo asumo porque debe surgir con cierta frecuencia a todos (quienes al menos tampoco conocen el futuro). ¿O tal vez parece que mi flujo de trabajo es defectuoso?

    
pregunta MasterMastic 14.11.2015 - 13:59

2 respuestas

17

Hay varias formas de resolver esto.

Si desea realizar los cambios para la primera confirmación sin interferir con sus cambios actuales, es posible que desee utilizar git stash . Esto guardará todos los cambios abiertos, permitiéndote restaurarlos más tarde. Use git status para ver que ya no están presentes. Ahora crea la primera confirmación como estás acostumbrado. A continuación, puede usar git stash pop para 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 con una parte de su trabajo. Para hacerlo, puede usar el índice (también conocido como área de preparación) provisto por git. Esta es un área especial que puede utilizar para preparar compromisos. Suponiendo que haya cambiado varios archivos, puede agregar cada uno de ellos al índice usando git add . Al hacer git commit solo se confirmarán los archivos agregados al índice. git status le mostrará qué partes de sus cambios se confirmarán y cuáles no. Por ejemplo, se verá de esta manera 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 estés haciendo git commit en este estado, solo los cambios en a.txt se agregarán a tu confirmación.

Además, puede revisar los cambios exactos que se confirmarán 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 usando "git add --patch b.txt". git le proporcionará un modo interactivo que le solicitará cada cambio en el archivo dado si se debe agregar al índice. Esto podría complicarse 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: enlace

También es posible que desee leer más sobre la adición interactiva aquí: enlace

    
respondido por el lucash 14.11.2015 - 15:35
5

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

Hago esto con frecuencia cuando me caigo en los agujeros de los conejos como lo describiste. Esta es una excelente manera de hacer ese compromiso sensible o como precursor del compromiso principal.

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

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

    
respondido por el Greg Burghardt 15.11.2015 - 02:20

Lea otras preguntas en las etiquetas