Problemas con el model de ramificación de Git

Estoy implementando el exitoso model de fusión git de Vincent ( http://nvie.com/posts/a-successful-git-branching-model/ ). Así que tengo un repository principal "principal" en nuestro server principal con 2 twigs principales: maestro y desarrollo. Todos los desarrolladores de mi equipo deben include esto en un repository personal y crear localmente un clon de este personal. Deben trabajar en su personal y luego crear una request de extracción / fusión.

Escenario: necesito desarrollar una nueva function genial.

  1. Tengo origen apuntando a mi tenedor personal.
  2. Agrego "principal" como control remoto adicional.
  3. Ejecuté "git fetch -p main" y eso debería get todos los cambios de main y sincronizar mi local.
  4. Creé una nueva twig desde el desarrollo "git checkout -b feature / cool_feature develop".
  5. Agregar, Commit …
  6. Pregunta 1.
  7. Pregunta 2
  8. Abro una request de fusión
  9. El gerente de integración que aprobó y se fusiona en principal / desarrollar
  10. Pregunta 3

Estas son mis preguntas:

  1. Durante mi trabajo en la function debería search el "principal"? En caso afirmativo, ¿debería fusionarme en mi sucursal de características o en mi sucursal de desarrollo local?
  2. Después de que termine mi function, debo fusionarla con mi twig de desarrollo local y enviar a origen (repository personal) o la dejo aparte y empujo solo la twig (creando una twig remota)?
  3. Si una twig se introdujo en mi repository personal, ¿debería eliminarla ahora?

Espero que esté claro, Tnx por adelantado.

El paso 3 solo actualiza tus references remotas. No se sincroniza con sus sucursales locales. Entonces en el paso 4, donde ejecutas git checkout -b feature/cool_feature develop , estás creando la twig de tu twig local desactualizada, a less que estés haciendo algo más para actualizarla.

Pregunta 1

Como de costumbre, depende. Fusionarse desde la línea principal puede introducir "compromisos inútiles" (como Linus los llamó) y puede saturar el historial. El rebase a menudo es una mejor opción aquí, especialmente si la twig es realmente su twig privada. Si esa twig tiene que ser compartida con otros para que ellos la usen, entonces te metes en un territorio interesante y peligroso con rebase, y la fusión se convierte en una mejor solución.

Para ser más específico, si durante el ciclo de su desarrollo se introducen nuevos cambios en el flujo ascendente, los volvería a incorporar e incorporaré a mi twig cuando me plazca. Puedo esperar hasta que mi function se implemente por completo, si no lleva mucho time implementarla, o puedo hacerlo de inmediato, especialmente si se ha realizado un cambio cerca del área en la que estoy trabajando.

Pregunta 2

Si usa rebase, entonces main ya está incorporado. Si no rebase, tiendo a evitar la fusión adicional a less que crea que va a causar un problema, y ​​hay testings que se ejecutan y los resultados integrados finales.

Usted lo empujaría a la twig, no se fusionaría con el develop .

Pregunta 3

Después de que la twig se haya fusionado en el repository main , puede borrar la twig.

Otras observaciones

Presta atención al consejo de @michas. Dependiendo de su situación, el model de NVIE puede no funcionar bien para usted.

Además, es posible que no haya pensado en esto, pero ¿cómo va a mantenerse actualizado localmente? ¿Qué twig rastrea: origin/develop o main/develop ? Pido sacar a la luz un par de cuestiones. En primer lugar, deberá mantener su sucursal de desarrollo local actualizada de alguna manera. Si está rastreando origin/develop entonces necesitarás hacer algo como git merge --ff-only main/develop para git merge --ff-only main/develop los commits nuevos en tu branch. Alternativamente, puede hacer que su develop local sea el main bifurcación en su lugar: git branch --set-upstream develop main/develop . Esto significa que su logging personal en vigencia tendrá una twig de develop desactualizada, pero no causará ningún daño.

FWIW, debido al hecho de que las sucursales locales no están actualizadas con git fetch , y git pull puede presentar commits inútiles, he estado usando un script llamado git-ffwd para mantener mis twigs actualizadas. Realiza la búsqueda y actualiza las twigs locales de seguimiento siempre que las twigs no diverjan.

Finalmente, algunos de los problemas que rodean a los controles remotos y mantenerlos actualizados si sigue a @michas consejos y solo funciona desde un repository central. Eso es lo que implementamos en mi lugar de trabajo, y ha funcionado bien.

Primero, ten un poco de cuidado con ese "model de ramificación git exitoso". – Podría encajar perfectamente en tu proyecto o podría ser totalmente erróneo. – Siempre depende de la situación.

¿Hay alguna razón por la que necesita un repository separado para cada desarrollador? – Cada desarrollador tiene que clonar el repository principal para trabajar en los files, por lo tanto, cada desarrollador ya tiene un repository personal como copy de trabajo.

¿Por qué no tener un único depósito central y una twig para cada característica? Si lo necesita, puede restringir quién puede presionar en qué twig.