Estrategia de fusión / rebase de Git para el desarrollo de un solo usuario

Estoy usando git para un proyecto de C ++, y soy el único desarrollador. Además de mantener el historial de códigos, estoy usando git porque quiero poder probar una nueva característica sin modificar el código original hasta que esté listo para incorporar la nueva característica en el código original. Estoy usando Github, pero soy el único desarrollador.

Entonces, así es como me imagino que mi historial de commit podría verse (las flechas denotan commits hijo, y las flechas entre twigs están implícitas):

A1 ---> A2 ---> A3 B1 ---> B2 / \ / \ X1 ---> X2 -----------> X3 ---> X4 -----> X5 ---> (...) 

En el historial anterior, A y B representan características (o cambios) que hice. En esta historia, trabajé primero en A , y luego de terminar A comencé B Obviamente, puede haber momentos en los que trabaje en funciones nuevas por separado en paralelo, pero en este ejemplo hipotético (y probablemente la mayor parte del time en mi desarrollo real), las características se trabajan en serie.

En este context, tengo dos preguntas relacionadas. Creo que es apropiado consolidar ambas preguntas en una sola publicación SO.

(1) ¿Tiene sentido crear solo una twig de "nueva característica" (por ejemplo, testing) para ejecutar junto con el maestro que se utilizará para desarrollar A y B (y las nuevas características posteriores)? (De ser así, ¿cómo administraría este process de cambio entre maestro y testing, fusionando o volviendo a establecer las testings en el maestro, y luego cambiando a las testings nuevamente para trabajar en otra característica nueva?)

(2) Dado que soy el único desarrollador, ¿tendría más sentido combinar o rebase al incorporar una nueva característica en el máster? Soy nuevo en git, así que por favor explica por qué. Si la respuesta es "depende", explique cómo decidir entre los dos.

Usamos este model en mi lugar de trabajo, y creo que funciona bien: http://nvie.com/posts/a-successful-git-branching-model/

Así que aquí hay algunas suposiciones de ese enlace:

Master siempre es 100 por ciento estable todo el time siempre.

Master obtiene una fusión del desarrollo cuando el desarrollo es estable y finalizado.

Para cada característica, haces que se desarrolle una twig.

Cuando la característica es estable, fusiona la twig de características para desarrollarla.

Prueba todas las funciones agregadas para desarrollar para garantizar que todo lo que ha agregado sea estable con cada otra function que haya realizado.

Luego fusione back to master cuando eso sea todo 100 por ciento.

1: Dado que la 'característica' A y B se superponen significativamente, o dependen en gran medida la una de la otra, puede ser conveniente desarrollar ambas en la misma twig. Si no lo hacen, y usted tiene problemas en la testing de desarrollo, puede eliminar las características mientras depura como un método de diagnóstico. Es tu llamada. Sin embargo, es posible que tengas que fusionarte para desarrollar tus twigs principales en caso de que llegues más lejos de lo que crees, principalmente porque otras personas habrán cometido cosas que pueden entrar en conflicto con tu sucursal actual, en caso de que traigas a otra persona.

Personalmente me gusta tener una function por twig, y ​​es solo un poco de trabajo hacer que las cosas vuelvan a desarrollarse en su sucursal. Eso requiere un poco de trabajo a veces ya que tienes que get cambios del desarrollo. Es una compensación, de verdad.

En cuanto a tener una function en paralelo: puede tener tantas twigs de características como desee. Entonces, si te aburres de la function en la que estás trabajando actualmente, solo crea una nueva twig para desarrollarla y trabaja en eso. Dirige cualquier problema de fusión en el desarrollo antes de que pase a maestro.

2: No podemos utilizar rebase en el context que especificó, ya que estamos compartiendo nuestras sucursales con otras personas. Yo diría que solo use merge así que si traes a alguien más a la mezcla, y listo, no hay problema. También esto:

http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

Espero que esto sea útil.

  1. Crea nuevas twigs para cada característica. Las sucursales son extremadamente baratas en Git (literalmente, solo escriben 41 bytes en un file) y son fáciles de administrar.
  2. Depende, pero no tanto como crees. De cualquier manera, terminarás con el mismo código. La pregunta es cómo quieres que se vea la gráfica de tu historia. Al volver a basar todo el time, se obtiene una historia lineal; eso es fácil de razonar. La bifurcación con confirmaciones de fusión conserva información sobre exactamente cuándo comenzó una característica y cuándo la fusionó en relación con otras twigs. A veces esa información es útil, a veces solo es ruido. Para hacer las cosas más confusas, la git merge pnetworkingeterminada de git merge solo a veces crea uniones de fusión (hará una fusión de avance rápido si es posible).

    Si desea un gráfico de historial que se parece a su gráfico anterior, debe hacer las dos cosas:

     git checkout feature/foo git rebase master git checkout master git merge --no-ff feature/foo 

    El único consejo concreto que tengo aquí es que no debes volver a escribir (rebase) el historial que has compartido con otros.