Cómo limitar las modificaciones de files a una sola twig en Git

Estoy empezando a aprender Git, leyendo el libro de ProGit de vez en cuando. He oído que la característica más poderosa de Git son las twigs, así que traté de usarlas. Estoy pirateando el proyecto de KDE, por lo que hay un server remoto y una copy local.

Entonces esta es mi situación. He codificado una corrección de error, pero el desarrollador responsable de esa área de código se ha desconectado sin haberme dado un shipit, por lo que decidí hacer una reparación diferente mientras tanto. Escuché que las twigs pueden (y más importante aún, deberían) usarse para tales situaciones. OK, creé una sucursal local

git branch bugfix 

luego se cambió a esa twig

 git checkout bugfix 

ad luego descubrió que los files que había modificado para la corrección original todavía se modificaron. (Por supuesto, necesitaba un directory limpio para poder enviar solo el segundo arreglo de errores sin el primero). Bueno, no hay problema, pensé, reiniciemos si eso es lo que el git status me dice que haga. Hice un reinicio y de hecho obtuve un dir limpio. Pero bueno, después de volver a dominar

 git checkout master 

¡los files modificados ya no se modificaron allí! Fue un dir limpio.

Ahora, ¿cuál es el punto de las twigs? ¿No puede haber dos versiones de un file, modificado en una twig y no modificado en otra? Sé de git stash , pero si lo hago, eliminar los cambios matará a la segunda corrección de errores, porque IIRC stash simplemente reemplaza un file por otro, no se realiza ninguna fusión.

¿Qué estoy haciendo mal aquí? ¿Por qué es imposible hacer que el file se modifique en una twig y no se modifique en otra?

Entonces, esto es lo que sucedió. Comenzaste con una confirmación A del desarrollador original. Corrigió algunos errores y ahora está en B. Hay una twig remota que apunta a A llamado origin/original-branch , y hay una twig local que apunta a B llamada my-changes . No sé cómo se llaman realmente (use git branch -a para enumerarlos).

 ....-> A -> B
         ^ ^
         |  + - mis-cambios
         |
         + - origen / original-branch

Si estás en B y creas una twig y comienzas a hacer cambios, obtendrás esto:

 ....-> A -> B -> C
         ^ ^ ^
         |  |  + - corrección de errores
         |  |
         |  + - mis-cambios
         |
         + - origen / original-branch

Esto no es lo que quieres. Tu quieres esto:

                + - mis-cambios
                v
 ....-> A -> B
          \
            -> C
         ^ ^
         |  + - corrección de errores
         |
         + - origen / original-branch

Entonces, debe hacer que su nueva sucursal comience donde está la sucursal del otro desarrollador.

 git branch bugfix origin/original-branch git checkout bugfix 

Eso especifica que la nueva twig comienza desde el trabajo del otro desarrollador. Si haces esto en su lugar:

 git branch bugfix # not what you want 

Esto hará que la twig de bugfix inicie desde donde se encuentre en este momento.

Para "recordar" un file modificado en una twig, necesita confirmar sus cambios (files agregados, eliminados o modificados): git commit -a (el argumento -a significa "todos los cambios") pero definitivamente necesita entender git branches. Este libro es muy útil.

Debe enviar los files a una twig para que estén en esa twig.

En su caso, hizo algunas modificaciones a algunos files, pero no los ingresó en ninguna twig.

Lo que podrías haber hecho fue:

  1. git checkout -b bugfix
  2. git commit -am "Fixed some bugs"
  3. git checkout master
  4. git checkout -b bugfixtwo
  5. En este punto, su trabajo original estará en master, sus primeros cambios serán corrección de errores, y estará listo para hacer un nuevo trabajo en bugfixtwo

git checkout -b bugFix crea y verifica una twig en un solo paso.