Flujo de trabajo / estrategia de git óptimo para requestes de extracción para proyectos de código abierto

Estoy buscando una estrategia clara, simple y óptima para trabajar en un proyecto público, que incluye:

  1. tirando cambios recientes
  2. agregando mi trabajo en la parte superior de la historia
  3. enviar request de extracción para revisión con historial limpio

Por óptimo me refiero a un número mínimo de pasos, y lo más importante,

Máxima automation y mínima posibilidad de crear un conflicto .


En mi configuration, estoy trabajando en mi twig de desarrollo local. Digamos que decido que está listo para una request de extracción. ¿Cuáles son mis pasos y cuáles son las reglas a seguir para evitar problemas?

  1. Primero necesito asegurarme de que mis commits más recientes estén en la parte superior del historial actual. Así que necesito rebase a rebase mis nuevos commits sobre los cambios públicos más recientes. No deseo merge para evitar una merge commit adicional, que no es de interés público:

    git rebase origen / maestro dev

  2. Ahora mi nuevo historial de commit está limpio y se encuentra en la parte superior de la twig master pública más reciente. No puedo push directamente al origin público ya que no tengo acceso de escritura. En su lugar, lo empujo a mi repository remoto bifurcado en Github. Pero aquí está la pregunta:

¿A qué twig remota debería presionarlo?

El problema es el historial limpio : quiero que esa twig remota sea exactamente idéntica a mi desarrollador local. Entonces, el mejor candidato parece ser una nueva twig de funciones clonada desde el origin/master :

¿Alguna forma sencilla de hacerlo en Github?

  1. Ahora tengo una copy exacta de origin/master en mi repository bifurcado, ya que mi nueva sucursal dice new-feature-x . Necesito actualizarlo para convertirme en una copy exacta de mi twig de desarrollo local:

¿Cuál sería la forma más simple y confiable de hacerlo?

  1. Así que con suerte ahora tengo la twig new-feature-x en mi repository bifurcado que puedo enviar para una request de extracción al repository de origin . Asumiendo (y esperando) no habrá ningún conflicto, ese paso es fácil.

Entonces eso tendría una estrategia perfecta si se tienen buenas respuestas a las preguntas anteriores.

¡Cualquier ayuda es apreciada!


EDITAR.

Muchas fonts se refieren a un exitoso model de ramificación de Git . Sin embargo, esto no parece adecuado para proyectos públicos con muchos queueboradores. El proyecto público puede que ni siquiera tenga una twig de development o algo similar. Y tener esa sucursal en mi repository local indefinidamente podría ser una molestia actualizarlo con cualquier request de extracción que sea aceptada / enmendada / rechazada, y así sucesivamente.

Además, este model sugiere mantener todos los loggings de fusión. Pero mis fusiones internas no son útiles para el público, solo agregan gastos generales innecesarios. Como mencioné anteriormente, quiero hacer una request de extracción con historial limpio para hacer el trabajo de los mantenedores lo más fácil posible .


He encontrado el siguiente command extremadamente útil antes de cualquier push :

 git pull --rebase upstream master 

Aquí estoy usando un control remoto llamado "upstream" para el repository público (y "origin" para mi propio fork).

Este command extraerá el estado actual de la twig principal del repository público y lo sincronizará con mi twig de características local que voy a enviar para la request de extracción. Si hay algún conflicto, puedo verlos y resolverlos todos en esta etapa, cómodamente en mi máquina local.

Una vez hecho esto, hay muchas less posibilidades de tener conflictos al hacer la request de extracción real.

Una vez que haya bifurcado, debe git checkout -b feature-branch inmediatamente la git checkout -b feature-branch (con un nombre descriptivo apropiado para feature-branch por supuesto). Una vez que haya agregado algunos commits localmente, ejecutará git push -u origin feature-branch para crear esa twig en su fork remoto. Los futuros empujones en esa twig no requieren esos parameters.

Una vez que haya completado su trabajo, simplemente emita la request de extracción a cualquier twig especificada por el proyecto. Eso puede ser master o desarrollador u otra cosa, según las pautas.

Sin embargo, me gustaría advertir sobre el uso git rebase , porque si alguien más ha sacado la misma bifurcación, entonces rebase y git push -f entonces de repente tienes dos historias diferentes y pueden ocurrir cosas malas.

Lectura adicional:

  • Tenedor un repository
  • Usar requestes de extracción
  • Modelo de ramificación de flujo Git (no necesariamente específico de GitHub)