Cuando estoy usando Git, ¿debo volver a establecer la base de datos antes de fusionarme?

Question

Estoy trabajando en un proyecto de Rails a gran escala, y el equipo con el que estoy trabajando usa Github para administrar el proyecto. Si bien muchos cambios se trabajan localmente y luego se envían directamente a nuestra sucursal de desarrollo, creamos una rama cuando vamos a trabajar en un cambio muy grande. Cuando llegue el momento de fusionar esa rama nuevamente en desarrollo, a menudo trato de volver a desarrollar la base de mi rama de características antes de fusionar mi rama de características en desarrollo (para evitar sobrescribir el trabajo de otras personas). Encuentro que cuando hago esto, parece que me encuentro con los mismos conflictos de fusión dos veces. Me encuentro con una lista completa de conflictos mientras cambio de base, luego vuelvo a encontrar la misma lista de conflictos durante la fusión. ¿Debería volver a desarrollar la base de datos en mi rama de características antes de fusionar mi función en desarrollo, o debería fusionar mi función en el desarrollo?

Digamos que mi rama de características se llama "new_feature". Mi proceso de fusión con la rama de "desarrollo" es la siguiente:

git checkout develop 

git pull (this is set up on our rig to always pull rebase) 

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop 

git merge -no-ff new_feature 

(same set of merge conflicts again) 

Es como si la línea de tiempo cambia de mi rebase porque mi nueva rama de la característica de especie de espejo desarrollar todo el camino de vuelta, y luego desarrollar conflictos con una copia de sí mismo.

Answer 1

Bien, esto es demasiado largo para un comentario ahora.

Parafraseando el manual (git help rebase)

Assume the following history exists and the current branch is "new_feature": 

       A---B---C new_feature 
       /
      D---E---F---G develop 


    From this point, the result of either of the following commands: 

     git rebase develop 
     git rebase develop new_feature 

    would be: 

         A'--B'--C' <new_feature 
         /
      D---E---F---G <develop 

Ahora, si tuviera conflictos, el estado real después de la primera ejecución rebase será

   A'--B'--C'--[local state] 
      / ^
D---E---F---G   new_feature 
      ^develop 

donde [local state] es la combinación de conflicto que todavía tienen arreglar. vez que haya resuelto los conflictos de fusión y añadido los archivos resueltos en el índice, se corre git rebase --continue: ahora su estado será

   A'--B'--C'--H <new_feature 
      /
D---E---F---G <develop 

Obviamente en este punto new_feature fusión de vuelta a desarrollar pueden ser reenviados rápido como tal :

   A'--B'--C'--H <new_feature <develop 
      /
D---E---F---G 

pero si no es que obtendrá este lugar

   A'--B'--C'--H <new_feature 
      /   \ 
D---E---F---G---------------I <develop 

Ahora cualquiera de estos se prefieren de una perspectiva de la línea de tiempo, no es obvio por qué cualquiera tendría un problema ... a menos que nunca hayas completado la rebase y resuelto los conflictos con H, pero creo que git se quejaría de eso.

Answer 2

Me parece que está utilizando rebase al revés, pero podría ser solo un fraseo confuso.

Reequilibré la rama de la característica en desarrollo y luego (en desarrollo) hago un git merge --ff-only feature.

Answer 3

Dado que especifica "gran escala" y "rebase" en la misma pregunta, le aconsejo que no haga eso. Use fusiones en su lugar.

El uso de --no-ff en fusiones es excelente con el fin de preservar el punto de ramificación original. Yo apoyo usarlo.