¿Es aconsejable usar la ramificación con un proyecto de git de un solo hombre?

Question

Tengo un pequeño proyecto en git, del cual soy el único desarrollador. Por ahora, utilicé solo una rama principal para que realmente funcione.

Ahora el proyecto está funcionando de alguna manera y me gustaría implementar algunas características nuevas. La pregunta es, ¿debería crear una nueva sucursal para cada nueva característica y luego fusionarla?

El hecho es que mi flujo de trabajo mejorará la "rama de características" y la fusionará de nuevo a la "rama maestra" sin cambios la mayor parte del tiempo, ¿tiene sentido crear nuevas ramas?

Answer 1

Desde la página gitworkflows hombre:

Cualquier característica no trivial requerirá varios parches para poner en práctica, y puede llegar correcciones o mejoras adicionales durante su vida útil.

Cometer todo directamente en los ramas de integración conduce a muchos problemas: Bad confirmaciones no pueden ser sin hacer, por lo que debe ser revertida uno por uno, lo que crea confusión historias y más errores potenciales cuando se olvida de volver parte de un grupo de cambios . Trabajar en paralelo mezcla los cambios, creando confusión adicional .

El uso de "ramas de tema" resuelve estos problemas .

Debe usar ramas de tema (también conocido como ramas de características), incluso si usted es el único desarrollador.

Además de las razones citadas anteriormente, yo añadiría:

• Si usted tiene una característica que le llevará mucho tiempo para completar, trabajando en una rama de la característica le permite suspender fácilmente el trabajo de esa característica para trabajar en otra cosa.
• Si existe la posibilidad de que necesite admitir varias versiones de su código (es decir, su versión actual es v2.0, pero un cliente/usuario está utilizando v1.0, usar ramas de tema le permite fusionar fácilmente las correcciones de errores en múltiples versiones.

Answer 2

Regla de oro: si rompe el producto durante el desarrollo, bifurque. Simplemente suponga que encuentra un error en el tronco y desea repararlo.

Answer 3

Tiene sentido siempre que lo ayude.
Uso SVN para mis proyectos personales y, a veces, cuando quiero investigar una nueva característica o desechar un montón de código, me gusta derivarme de mi rama principal.

De esta manera puedo trabajar en la nueva funcionalidad durante un largo período de tiempo (léase: más de una confirmación) si no puedo siempre puedo volver a la rama principal y si tengo éxito puedo fusionar toda la rama o solo los cambios que tienen sentido

Answer 4

Yo diría que es probablemente una preferencia personal, pero en algunos de los proyectos en solitario en los que trabajo, a veces es útil crear una rama para el nuevo trabajo, dejando la rama principal disponible para corregir errores. Me encuentro en el medio de trabajar en algo nuevo, cuando alguien viene reportando un error a la versión existente. En esa situación, puedo archivar fácilmente el nuevo código y corregir el error en la rama principal, luego volver a las cosas en las que estaba trabajando. Entonces, al final, combínalos.

No suelo ramificarme para cada nueva característica. Normalmente, no trabajo en varias funciones al mismo tiempo ... solo de vez en cuando, en cuyo caso depende de cuánto se solapen las dos funciones en el archivo, lo que me haría ramificar de nuevo.

Answer 5

Yo diría que sí, para mí cada vez que introduzco el código en el entorno de producción, creo una rama de versión. Entonces, si algo sale mal, simplemente puedo regresar a esa rama y hacer que la solución elimine el problema y luego fusionar mi código de nuevo en el enlace.

Answer 6

debo crear una nueva rama para cada nueva característica y la fusión de nuevo después?

Sí, porque a mitad de camino a través de la implementación de esta característica, se encuentra un error que cortaba en su código de producción, y se le agradece que se puede volver a git checkout master el código que se encuentra en producción y solucionarlo. Mi regla es tener siempre mi rama principal en un estado desplegable.

Answer 7

yo digo que sí a tener ramas de funciones, incluso durante un proyecto 1 persona triviales sin clientes.

la razón es el flujo de trabajo. Si se utiliza un único flujo de trabajo que se puede aplicar a través de toda la En los proyectos en los que participas, cada vez hay menos errores y menos decisiones para pensar. También hace la vida más fácil si tu proyecto "trivial" cobra vida propia :-).

(Un único flujo de trabajo es un ideal, por supuesto, pero cualquier cosa que ayude ...)

Answer 8

Agregando a lo que han dicho: ramas son tan fáciles de crear & mantienen en Git, por qué no hacer una rama? Incluso si nunca necesita hacer una corrección de fallas/actualización en la rama anterior, aún obtendrá metadatos adicionales sobre su base de código a través de las sucursales que le complacerá tener en un año.

Soy un gran fan de hacer todo tipo de ramas de características, por dos razones: primero, puede estructurar su flujo de trabajo de manera que la rama maestra siempre esté lista para enviar (lo cual es genial) y segundo, una vez tener un poco de historia con un montón de ramas características y tal, mirar el árbol en algo como gitk o qgit te da una sensación de alto nivel realmente genial para el historial de la base de código que una sola línea no tendría.