2012-04-20 15 views
5

¿Cómo recomendaría administrar la funcionalidad específica del cliente y cambiar las solicitudes dentro de Git-flow, o Git en general? ¿Deben las características específicas del cliente estar en una rama separada dedicada al cliente? (Cada cliente tiene su propia sucursal de la sucursal de desarrollo). ¿O deberían estar en un repositorio separado? (Cada cliente tiene un repositorio dedicado, con el repositorio principal como nuestro repositorio principal).Git-flow y funcionalidad específica del cliente

+0

pregunta interesante. ¿Pero es un problema de git-flow o simplemente un problema de git? (Nota, soy nuevo en git y git-flow, así que no estoy siendo sarcástico allí). –

+0

Bueno, estamos tratando de seguir la estructura de git-flow, pero esto puede aplicarse a Git en general. P.ej. ¿Cuáles son las prácticas usuales para manejar tales casos? – Dario

Respuesta

2

Crearía un repositorio separado para su base y sus clientes. Los clientes tendrían una base que tendría una sucursal remota, siendo su base. Cuando un cliente necesita una nueva versión, es mucho más fácil de esta manera. Si colocara todos los clientes en un repositorio, tendría que cambiar manualmente la rama de integración/desarrollador antes de hacer un lanzamiento de lanzamiento de flujo de git. Esto limitaría su capacidad de trabajar en múltiples lanzamientos para diferentes clientes.

4

Parece que tiene una base de código que usan todos los clientes, y luego tiene algunos "hacks" para la funcionalidad específica del cliente.

En mi opinión, tendrías todo el código "base" en la rama principal. Todos los clientes tendrían una sucursal específica del cliente. Tenga cuidado y sepa dónde se están realizando los cambios.

De vez en cuando, asegúrese de volver a establecer la base de las ramas de sus clientes, básicamente llevándolos al código base y luego volver a reproducir todos sus cambios específicos además de eso.

Rebase puede ser bastante confuso hasta que lo vea en acción.

Uso de números de confirmación secuencial para mayor claridad. Los compromisos no son numéricos en la vida real

 
Master is at commit 10 
\ 
    Branch has commits 10, 11, 12, 13, 14, 15 (notice it has commit 10 as well) 
| 
Master commits 16, 17 


When you rebase: 
    Master has 10, 16, 17. 
    Branch has 10, 16, 17, 11, 12, 13, 14, 15 

El orden aquí es muy importante. Rebase rebobina la rama a 10, aplica 16 y 17, y luego reproduce sus cambios de 11, 12, 13, 14 y 15.

En este punto, mientras no haya conflictos, la sucursal está lista para fecha con el maestro Y tiene los cambios específicos del cliente.

Cuestiones relacionadas