Es Git lo suficientemente inteligente como para fusionarse después de refactorizar

Supongamos que tengo una class.

package org.my.domain; public class BestClassEver{} 

Mi flujo de trabajo

Mediante algunas refactorizaciones, cambio el package de esta class.

 package org.another.domain; public class BestClassEver{} 

Lo envío a mi repository local usando git y lo envío a un repository remoto.

 git add . git commit -m "Refactoring" git push origin master 

Flujo de trabajo de otro desarrollador

Otro desarrollador modifica la class, sin tirar de mis cambios.

 package org.my.domain; public class BestClassEver{ private String something; } 

Luego se compromete y empuja al repository remoto

 git add . git commit -m "Some Changes" git push origin master 

Preguntas

  1. ¿Git fusionará los cambios del otro desarrollador en la class?
  2. Si no, ¿qué sucede?
  3. ¿Es este flujo de trabajo algo que necesita ser coordinado entre el equipo?

  1. Git no permitirá que el otro desarrollador presione sus cambios sin tirar.

Lanzará un error de que ambos refs no coinciden y, por lo tanto, su sucursal local debe actualizarse con los refs remotos.

Eso es todo lo que hay que saber sobre eso. Si hay cambios en el repository remoto, a less que realice un forzado, git no le permitirá presionar los cambios si hay cambios en el control remoto.

EDITAR

Una vez que tira, si hay conflictos en el file, el desarrollador deberá corregir cualquier conflicto, comprometerlos y solo entonces podrá empujar.

Si no hay conflictos, git fusionará automáticamente esos cambios y el desarrollador podrá presionar después de la extracción.

EDIT OTRA VEZ

No me di count de que estabas moviendo el file. En cualquier caso, ejecutar el git status le daría una idea del estado de su repository local después de un tirón. Si hubo algún conflicto, podrías corregirlo.

NOTA

En git rebase o git pull --rebase se usan generalmente para darte un historial de confirmaciones mucho más limpio, ya que aplicarán prácticamente cualquier cambio local además de cualquier otro cambio que se haya realizado.

Por otro lado, git pull y git merge normalmente harán un compromiso adicional para vincular los cambios en las twigs.

Para más información eche un vistazo a esta guía Git Rebasing

Siempre es una buena idea dejar que las personas trabajen en diferentes partes del progtwig.

Merge o rebase en este caso debería ser completamente automático, pero en el mundo real siempre es un poco dramático y, a veces, hay algunos conflictos. Por supuesto, esta combinación / rebase se realizará después de que el server rechace la inserción para que el beeing no sea de avance rápido.

Cuando tal cosa falla, algunas soluciones incluyen:

  1. Simplemente repite "refactorización" en la otra twig antes de la fusión;
  2. Convirtiendo el trabajo en parche ( git format-patch ), editando el parche (aplicando ese "refactor") y aplicando el parche editado ( git am ). Es como un rebase manual.

Creo que es mejor separar la refactorización que complica la fusión (una que implica renombrar, por ejemplo) y el reajuste menor habitual.

A veces, para un refactorado que complica la fusión, se puede escribir un script (como find -name '*.c' -exec sed 's/something/anything/g' -i '{}' ';' ). El script se utilizará para repetir la refactorización varias veces en varios lugares cuando lo necesitemos, evitando así combinar el código refactorizado con uno no refactorizado.

SÍ. Git puede identificar esos cambios. Estoy trabajando en un proyecto usando git en mi propio tenedor (bifurcado desde el origen). Mientras tanto, otro desarrollador refactorizó la base de código en la horquilla original, que incluye cambiar la estructura del package.

Usé los siguientes commands:

  • git stash save // ​​esto guarda todo tu trabajo en un alijo personal
  • git pull // obtiene todos los últimos cambios en la horquilla principal y se fusiona
  • git stash apply stash @ {0} // o lo que sea que el alijo es donde guardaste tu trabajo personal

Ahora tendrá la base de código refactorizada + sus cambios. Ahora puede comprometerse sin ningún conflicto y el embalaje no se cambiará.

Solo tenga en count que en mi caso esperé a que la horquilla original fuera refactorizada y luego envié mis cambios, que son solo cambios a pocos files y no reempaquetado.

También tenga en count que si ha agregado nuevos files, puede que tenga que editar algunas importaciones para asegurarse de que las importaciones sean correctas. p.ej. import org.my.domain; ahora debe editarse para: importar org.another.domain;