git – cómo manejar confilictos

Aquí está el escenario:

El usuario A y B tiene el mismo código fuente. El usuario A realiza cambios => agregar => confirmar => presionar. El código fuente en el repository remoto se cambia.

El usuario B comienza a cambiar sin tirar. (o tal vez se apliquen cambios en el repository remoto después de que el usuario B haya sacado el repository). Luego también quiere presionar. En este momento, el conflicto ocurre. Busqué mucho y no pude encontrar ninguna solución, pero para editar conflictos manualmente .

Pregunta: ¿Los conflictos de edición son manuales de manera eficiente? Especialmente en un gran proyecto? ¿Cuál es el enfoque?

Administrar conflictos de combinación manualmente puede ser una tarea engorrosa.

Pruebe git mergetool y se abrirá la herramienta pnetworkingeterminada mergetool, aunque primero debe instalar una herramienta mergetool. Hay varios mergetools que pueden ayudarte a resolver conflictos como opendiff , opendiff , kdiff3 , tkdiff , xxdiff , tortoisemerge , gvimdiff , diffuse , ecmerge , p4merge , araxis , vimdiff , emerge .

Después de instalarlo, simplemente ejecute y se abrirá la herramienta de combinación instalada, le proporcionará una guía que le guiará a través de cada conflicto y podrá elegir cómo fusionarse.

Si usa IDEs como IntelliJ , proporcionan una herramienta incorporada para arreglar conflictos de combinación.

La resolución manual de conflictos es el path a seguir. Conflicto significa que el desarrollador B confía en algún código que se modificó. Esto significa que tiene que adaptar su código a los cambios realizados por el desarrollador A. Eso es – para resolver este conflicto.

Algunas veces ese conflicto puede resolverse automáticamente. A veces se puede resolver simplemente eligiendo una opción como "nuestra después de la suya". Sin embargo, incluso si no hay conflicto en el sentido de git, es posible que el código aún tenga que ser corregido.

Por ejemplo: hay una function some_func que acepta algunos arguments. El desarrollador A lo renombra a some_new_name , mientras que el desarrollador B agrega la llamada a some_func en algún área de código completamente separada. La fusión ocurrirá sin ningún conflicto, pero el código no funcionará correctamente.

En realidad, tener un conflicto puede ser mejor que no tenerlo: se recibe la advertencia temprana de que el código que escribió debe cambiarse.