git rebase una rama que se ha colaborado en?

Question

Después de leer este artículo, tiene sentido cambiar la base para recoger los cambios de la rama principal a mi rama de la característica: Git workflow and rebase vs merge questions

clone the remote repo 
git checkout -b my_new_feature 
..work and commit some stuff 
git rebase master 
..work and commit some stuff 
git rebase master 
..finish the feature 
git checkout master 
git merge my_new_feature 

Esto funciona muy bien si la rama de la característica es local en mi máquina y que puede volver a escribir la historia como me plazca.

Pero, ¿qué sucede si colaboro con alguien más en la rama de características? ¿Cómo podemos llegar a los últimos cambios de la rama principal en nuestra rama de la característica ahora que nuestra rama de la característica se mantiene en el repositorio remoto?

Así que se fusionan? ¿O hay otro método astuto de GIT para hacer esto?

¡Gracias de antemano!

Answer 1

Si está trabajando solo los rebases no hacen nada. No has cometido nada nuevo para dominar.

Su fusión será un avance rápido unir y que podría hacerlo por no echarle un vistazo en absoluto con

git push . HEAD:master 

Si usted está trabajando con alguien o no, la fusión de obra que está en maestro en su función la rama es una mala práctica. Se llama fusión inversa. La razón por la cual es malo es que ahora no tienes un trabajo atómico. la historia del maestro está enredado con su toma de función de trabajar con esta función, tales como cambio de base, imposible en muchas situaciones.

Tienes que pensar en tu estrategia de ramificación y en lo que quieres lograr. Esta es la mía:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

se puede ver que cada rama se inicia desde el mismo lugar. Tiene una rama de integración separada y una rama candidata de lanzamiento para mezclar y combinar las características que desea sin contaminarlas.

En cuanto a la colaboración en una función con un colega, depende de qué tan grande es una característica (la granularidad de su trabajo). Si es grande, puede aplicar el proceso anterior a la función en sí y, por el contrario, bifurcar por tarea.

Si se trata de una función pequeña que puede combinar o volver a establecer en esa rama, no importará demasiado. En este punto, todo se reduce a lo que el equipo se siente cómodo.

Answer 2

Hay una solución para su caso sin cambiar a un flujo de trabajo completamente diferente.

En cuanto a la obtención de correcciones de su rama principal en ramas de características, como ya descubrió, lo mejor es seleccionar estas confirmaciones particulares. Pero prefiero tener ramas de tema, incluso para las revisiones en lugar de corregir en la línea principal, de esa manera puedo fusionar esas correcciones en cada característica bloqueada por ellos.

Para mantener el historial de desarrollo de características lo más limpio y lineal posible, todos los colaboradores deben usar git pull --rebase para obtener actualizaciones para que no se produzcan confusiones de fusión sin sentido en el camino.

Si aún desea volver a establecer una base de funciones colaborativas sobre la rama de desarrollo principal actual (para pruebas de integración continua u otros fines) o reescribir su historial de otra manera, puede hacerlo una vez que la función esté completa/completa, solo antes de la fusión a la rama principal, pero debe hacerlo en una nueva sucursal local/privada separada.

Aquí es cómo volver a crear sus cambios de-tema (saltar cereza-picks) en una nueva rama de maestro:

$ git checkout -b feature_final feature # jump to a new branch for grooming 
$ git rebase [-i] master    # rebase topic changes onto master 

A partir de ahí es hasta qué hacer con la rama ascendente porcentualizada -push para QA o directamente para master (con --no-ff si desea hacerlo explícito en la historia).