Git & Github
  1. Git & Github
  3. Beneficios del uso de git branches frente a múltiples repositorys

Beneficios del uso de git branches frente a múltiples repositorys

Estamos haciendo desarrollo para el código de automation.

Nuestro código automatiza los productos de la compañía y se sincroniza con una versión de producto en particular.

Actualmente, tenemos 1 gran repository de Git con múltiples twigs en él: v1.0, v1.1, v2.0 (la automation para la versión 1.0 va en la twig v1.0, y así sucesivamente).

¿Cuáles son las ventajas y desventajas de tenerlos en un único repository con twigs y mantener cada código de versión en un repository separado?

Ambas soluciones pueden funcionar, la respuesta que estoy buscando es una list de pros / contras para cada enfoque.

Sé que muchos equipos están utilizando twigs para aislar las etapas temporales en el desarrollo, como la corrección de errores o una nueva function, y luego fusionan el trabajo en la twig de desarrollo principal.

Otros modos de trabajo que conozco tienen diferentes twigs para el desarrollo, lanzamiento, etc., para separar las revisiones "más limpias" del código de las sucias en las que se trabaja constantemente.

Ninguno de estos suena similar a lo que estamos haciendo actualmente.

* Tenga en count que algunas modificaciones en una versión particular que hacemos son relevantes para todas las versiones de productos, mientras que otras no.

Varias twigs

Pros:

  • solo un repo para administrar (sus puntos automatizados a uno remoto)
  • comparación (diff) entre las twigs posibles directamente de ese repo
  • puede extraer cualquiera de esas twigs de ese repository a cualquier otro repository indirecto que pueda necesitarlo

Contras:

  • desorder de twigs (necesita administrar / eliminar la sum de las twigs)
  • las tags son para todo el repository (no solo para "algunos productos")

Múltiples repos

Pros

  • puedes sacar del repository principal solo lo que necesitas y trabajar desde allí
  • puedes limpiar fácilmente "twigs" viejas (simplemente elimina ese repository específico)

Contras

  • duplicación de repo (toma más espacio)
  • gestión de repositorys (debe señalar los controles remotos correctos)

Yo diría que el enfoque de repo único es un enfoque más simple y más clásico.
Dicho esto, si tiene muchas versiones (que deben limpiarse regularmente), también puede funcionar el aislamiento de esas versiones transitorias en su propio repository.

Aquí hay una respuesta interesante usando tags y twigs de Git de esta pregunta de desbordamiento de stack: http://sofes.miximages.com/a/2714318/1552414 (respuesta por None-da)

  1. Crea una label cuando llegues a una nueva versión. (v3.0.0)

  2. Cree una twig de la misma cuando necesite modificarla por primera vez 

     git checkout -b v3.0.0_branch v3.0.0

  3. Comprométase con la sucursal y cree nuevas tags cuando llegue a v3.0.1, v3.0.2, v3.1.0

No hace mucho time, mi empresa pasó por una discusión similar (pros y contras de las sucursales). Mientras hacía investigación, encontré la siguiente instrucción para ser útil. http://guides.beanstalkapp.com/version-control/branching-best-practices.html Espero que te ayude también.

Intereting Posts
¿Cómo organizas tus repositorys git?La fusión con MercurialEclipse tiene conflictos que se resuelven automáticamente cuando se fusionan en la línea de commandfusión parcial de dvcs (git, hg merge tracking)Exportar información de control de la versión e historial de RTC Jazz¿Existen progtwigs de control de versiones solo para el cliente?¿Por qué no implementar el código directamente desde el repository git o bzr?Se funde entre dos twigs en dos direcciones: ¿hay alguna buena razón o está completamente prohibido?Cómo fusionar el maestro remoto en dos confirmaciones antes que el maestro local actual