Después de un conflicto de fusión de Git, muchos archivos que no toqué se convierten en cambios que se cometen

Question

Así que estoy trabajando en una rama, realizo algunos cambios y ejecuto git merge master. Tengo un conflicto de fusión en uno de los archivos que modifiqué (que sé cómo manejar), pero por alguna razón, un montón de archivos que hice no táctil (pero que se actualizaron en el maestro) de repente entran en mi lista de "Cambios a ser cometidos".

¿Por qué es esto? ¿Y cómo soluciono esto? No quiero comprometer ninguno de estos cambios que no son míos.

Answer 1

Cuando intenta fusionar, todos los archivos que pueden combinarse automáticamente (por ejemplo, donde no tiene ningún cambio en su sucursal local pero que se han modificado en la rama de origen) se fusionan y organizan automáticamente. Los archivos que no se pudieron fusionar automáticamente se actualizan en su área de trabajo con marcadores de conflicto y debe corregirlos.

Git siempre ensambla nuevas confirmaciones en el área de preparación antes de comprometerlas. La fusión hace lo mismo. Se crea una nueva confirmación con todos los cambios de la rama de origen en el área de ensayo. En caso de conflicto, este proceso de actualización del área de ensayo se interrumpe y se le otorga el control. Es por eso que esto sucede. Una vez que se compromete, se creará una "fusión de compromiso" en el repositorio que tiene las ramas fuente y destino como padres.

En cuanto a "No quiero que se comprometa ninguno de estos cambios no realizados por mí", ¿por qué hizo una fusión en absoluto si no quiere ningún cambio?

Answer 2

Creo que el problema con esta forma de hacer GIT es que después de la confirmación, se realizará un "push". El "push" incluirá todos los archivos confirmados, incluidos los archivos que el "empujador" no tocó. Esto hace que el seguimiento sea muy complicado.

Answer 3

La razón por la que esto sucedió es porque lo más probable es que haya hecho lo contrario de lo que pretendía hacer.

Supongamos que su rama de trabajo se llama topic-branch.

En vez de hacer:

$ git merge master

que podría haber hecho:

$ git checkout master 
$ git merge topic-branch 

En Inglés, en lugar de combinar la rama master en topic-branch que podría haber fusionado topic-branch en master.

Para entender por qué esto logra el resultado deseado podemos examinar la declaración hecha en una respuesta anterior:

Cuando intenta una fusión, todos los archivos que se pueden combinar de forma automática (por ejemplo, cuando usted don' t tiene algún cambio en su sucursal local pero que se han modificado en la sucursal de origen), se fusionan y organizan automáticamente.

El problema que está teniendo es simplemente merge tratando de hacer su trabajo. Los archivos no se cambian en su rama de tema, pero están en la rama en la que se está fusionando.Si observa esto en la dirección opuesta a la combinación de topic-branch en master, el problema desaparece porque solo considera los archivos que ha modificado.

Conceptualmente, esto es lo que está haciendo merge (más here):

Deje el actual jefe se llama corriente, y la cabeza se va a combinar llamada fusión.

1. Identificar el antecesor común de la corriente y fusionar. Llámalo antepasado-commit.
2. Trate con los casos fáciles. Si el antepasado-commit es igual a merge, entonces no hagas nada. Si ancestro-commit es igual a current, , haga un fast forward merge.
3. De lo contrario, determine los cambios entre antepasado-compromiso y fusión.
4. Intenta fusionar esos cambios en los archivos actuales.
5. Si no hubo conflictos, cree una nueva confirmación, con dos padres, actual y merge. Establezca actual (y HEAD) para apuntar a esta nueva confirmación, y actualice los archivos de trabajo para el proyecto en consecuencia.
6. Si hubo un conflicto, inserte los marcadores de conflicto apropiados e informe al usuario. No se ha creado commit .