[OT] Uso de repositorios git por equipos de trabajo

[J. Hernán Ramírez R.]

Me disculpan el Off Topic.. pero mi duda podría ser de mucha utilidad

Tenemos una herramienta desarrollada en angular + django-rest-framework

Lo que se quiere es tener un repo mini para cada equipo de trabajo ejemplo

team 1: solo tiene acceso al módulo 1

team 2: solo tiene acceso al módulo 2

ProjectManager al repo con todos los módulos y debe integrar todos los feature realizados por team1 y team 2

por casualidad conocerán una herramienta o git command que permita manejar los merge de una forma efectiva?

Gracias de antemano

--
Salva un árbol. No imprimas este correo a menos que sea realmente necesario.

---------------------------------------------------------------------------------

J. Hernán Ramírez R  

http://about.me/hernanramirez - Linux User #97.898  

Mapas Libres OpenStreetmap Venezuela

---------------------------------------------------------------------------------

[Juancarlo Añez]

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Aunque creo que la estrategia de un repositorio por equipo indica que hay conceptos equivocados respecto a la gestión de proyectos de software.

--
Este es un mensaje del foro Python de Venezuela - http://www.python.org.ve
Para suscripciones y retiros: http://goo.gl/ug9by
---
Has recibido este mensaje porque estás suscrito al grupo "Python Venezuela" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a python-venezue...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Juancarlo Añez

tel:+58(414)901-2021
skype:juancarloanez

[Jesús Gómez]

Si flexibilizas un poco el nivel de control que quieres, y le sacas
provecho a la característica distribuida de Git, entonces tu situación
encaja muy bien con el patrón «Flujo de trabajo de un gerente
integrador»: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#wfdiag_b

El día 9 de abril de 2017, 7:58, Juancarlo Añez
<juancar...@gmail.com> escribió:

[Juancarlo Añez]

2017-04-09 9:59 GMT-04:00 Jesús Gómez <jgo...@gmail.com>:

Si flexibilizas un poco el nivel de control que quieres, y le sacas
provecho a la característica distribuida de Git, entonces tu situación
encaja muy bien con el patrón «Flujo de trabajo de un gerente
integrador»: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#wfdiag_b

Creo que faltan flechas en esos workflows...

En mi experiencia existen workflows manejables utilizando solo branches y tags:

• branch-per-feature. Se crea un branch para cada tarea, sea nueva funcionalidad, o corrección de defectos. En ambos casos debe haber una frase y un ID que permitan nombrar el branch de manera inambigua. 
• Se hace merge de la última versión blessed y se corren todas las pruebas antes de hacer push de un feature branch.
• frequent release tags (usando semver). El integrador hce merge de cada feature branch, coloca un tag aumentando el número de versión, hace merge a master y hace push a blessed.

Github y Bitbucket tienen buen soporte para ese tipo de workflow. El resultado es que cada quien se asegura de que sus cambios funcionan contra la última versión bendecida antes de compartirlos, con lo cual se mantiene la estabilidad y se minimizan los conflictos. Queda en el equipo on en su líder evitar el trabajo simultáneo en tareas que tocan los mismos módulos (serializar).

[Jesús Gómez]

El día 9 de abril de 2017, 10:26, Juancarlo Añez
<juancar...@gmail.com> escribió:
> ... Queda en el equipo on en su

> líder evitar el trabajo simultáneo en tareas que tocan los mismos módulos
> (serializar).
>

Esto para mi es la clave de este asunto.

J. Hernán, a menos que estés trabajando en algún proyecto super
secreto y estricto donde los equipos no deben tener acceso al código
de los demás equipos, entonces limitarlos a nivel sistemas,
herramientas y permisos puede llegar a ser un problema en si mismo más
que una solución.

> --
> Juancarlo Añez
> tel:+58(414)901-2021
> skype:juancarloanez
>

[J. Hernán Ramírez R.]

Esto para mi es la clave de este asunto.

J. Hernán, a menos que estés trabajando en algún proyecto super
secreto y estricto donde los equipos no deben tener acceso al código
de los demás equipos, entonces limitarlos a nivel sistemas,
herramientas y permisos puede llegar a ser un problema en si mismo más
que una solución.

'See' de acuerdo con su comentarios.. Pero la empresa quiere guardarse algunos procesos solo para algunos equipos; la integración me esta volviendo loco.. en fin.. 

Interesantes los enlaces el concepto de Submodules y Centralized Workflow.. 

Haré algunas pruebas y les comentaré.. gracias por sus aportes!!

 

 

> --
> Juancarlo Añez
> tel:+58(414)901-2021
> skype:juancarloanez
>
> --
> Este es un mensaje del foro Python de Venezuela - http://www.python.org.ve
> Para suscripciones y retiros: http://goo.gl/ug9by
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Python Venezuela"
> de Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes,

> envía un correo electrónico a python-venezuela+unsubscribe@googlegroups.com.

> Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Este es un mensaje del foro Python de Venezuela - http://www.python.org.ve
Para suscripciones y retiros: http://goo.gl/ug9by
---
Has recibido este mensaje porque estás suscrito al grupo "Python Venezuela" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a python-venezuela+unsubscribe@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Manuel Alejandro Márquez Ortiz]

Saludos Hernán, revisa git-flow, combina algunas de las caracteristicas mencionadas por los demás compañeros...

Acá el post original del autor en 2010 -> http://nvie.com/posts/a-successful-git-branching-model/

Puedes combinarlo con algun otro workflow si todavía necesitas más, en mi caso lo he combinado con algunas cosas que me gustan del  workflow de Gitlab, en el caso de querer ocultar ramas por equipos de trabajo (cosa loca por cierto) puedes revisar si la herramienta que estes usando para gestionar el repositorio te lo permite, Gitlab por ejemplo permite Bloquear ramas pero eso lo que hace es que no permite que desarrolladores sin permiso puedan hacer push a determinada rama...

Saludos...

--

[Juancarlo Añez]

2017-04-09 21:39 GMT-04:00 Manuel Alejandro Márquez Ortiz <buzon...@gmail.com>:

Acá el post original del autor en 2010 -> http://nvie.com/posts/a-successful-git-branching-model/

Ese es un workflow que funciona. Lo he aplicado usando:

• "release" en vez de "master'
• "master" en vez de "develop"
  

Así los desarrolladores quedan como "dueños" del repositorio donde ocurren más cosa, y pueden agregarse branches intermedios camino a "release" como "testing".

Una variación que se puede hacer:

• El repositorio para los releases y hotfix puede ser aparte (es lo que Torvalds hace con Linux).

Criticas:

• No deben haber flechas entre "hotfixes" y develop; los merges tienen que ser contra "master" (o sea, release)
• Podría hacerse un rebase antes de un merge de un feature branch, sobre todo si se usa "--no-ff". De esa manera los cambios son registrados contra la versión destino del merge.

Saludos,