2012-09-04 9 views
5

En mi compañía tenemos un software base que se personaliza para cada cliente. Hoy usando SVN tenemos una configuración como esta:Mejor práctica para proyectos personalizados múltiples y Git

/trunk 
/tags 
    … 
/branches 
    /client_project_x 
    /client_project_y 
    /client_project_z 

¿Cuál sería la mejor manera de organizar esto en git? ¿Tiene un repositorio remoto para cada proyecto y uno para el código base o tiene un gran repositorio remoto con varias sucursales?

Si utilizamos un repositorio remoto grande con varias ramas, ¿hay una forma de clonar solo una rama de un repositorio remoto?

Respuesta

2

Conceptualmente, no hay diferencia entre múltiples ramas en un repositorio y ramas en varios repositorios. El objetivo de DVCS es eliminar esa distinción. Desea pensar en términos de personas que necesitan acceder y controlar cualquier rama determinada. Si es común que cada desarrollador acceda al código de cada cliente, entonces será más fácil ponerlos todos en un repositorio central. Puedes elegir qué ramas quieres clonar o no, aunque clonar un repositorio completo es lo más fácil. Si necesita permisos de acceso muy diferentes en diferentes ramas, es preferible crear repositorios separados para ellos.

En otras palabras, configúrelo de cualquier manera que sea más fácil para los equipos de desarrollo y prueba.

+0

¿Cómo elegir qué ramas quiero clonar? –

+0

Mira [aquí] (http: // stackoverflow.com/questions/4811434/git-clone-only-one-branch). –

1

Los proyectos separados deben estar en repositorios separados.

(Es tan simple como eso con git No hay ninguna ventaja y un montón de desventajas potenciales a mantener un montón de relación -. O indirectamente relacionada - proyectos en un repositorio único, ya sea en un gran árbol o en ramas separadas.)

+0

¿Alguna sugerencia sobre cómo gestionar múltiples repositorios autocapturados de forma que sea fácil crear un nuevo repositorio remoto? –

+0

@MarcoPompei: 'git init --bare' en una ubicación accesible de forma adecuada es la forma más sencilla de crear un repositorio compartido" central ". –

0

git nació para hacer que las ramas/ramas de fusión sean tan sencillas, así que solo haga las sucursales que desee para nuevas funciones, pruebe las funcionalidades, trabaje con un subgrupo sin afectar al resto de la empresa. Linux, por ejemplo, tiene miles de sucursales y ¡están creciendo!

Mira this video para Linus Torvalds, que te ayudará mucho a comprender los valores "en mente" que tiene mientras desarrolla git.

0

I utilizar varios repos:

El núcleo está en un repositorio, cada plugin y cada cliente tiene su propio repositorio:

  • modwork (núcleo)
  • modwork_foo (configuración para el cliente "foo ")
  • modwork_app1 (una aplicación que se puede instalar para varios clientes)

n un solo archivo en el núcleo se modifica durante la instalación o el proceso de compilación. Cada cliente tiene el mismo núcleo. El núcleo contiene ganchos para métodos personalizados.

No me gusta modificar los archivos en el núcleo en las ramas para los clientes. Creo que esto se vuelve difícil si tienes más de 5 clientes.

Cuestiones relacionadas