Git Collaboration Strategies (Spanish).pdf
-
Upload
duongkhuong -
Category
Documents
-
view
266 -
download
1
Transcript of Git Collaboration Strategies (Spanish).pdf
1. Centralizado (Centralized Workflow)
2. Usando Ramas Puntuales (Feature branch Workflow)
3. Usando Ramas de Largo Recorrido (Git Flow)
4. Haciendo Bifurcaciones (Forking)
Flujos de Trabajo:
- El repositorio se encuentra en un servidor remoto.
- Cada colaborador necesita acceso para leer y escribir al repositorio central.
- Cada colaborador clona el repositorio remoto y envía cambios a éste mismo.
- Todo el trabajo se hace en la rama master.
Características:
- Este flujo de trabajo es demasiado simple, y a menos que trabajes sólo, tendrás que arreglar conflictos con mucha frecuencia.
- La rama master pierde su pureza. - No hay lugar para revisión de
código (a menos que uses email).
Desventajas:
- Sincronizar el repositorio local antes de empezar a trabajar.
- Recibir cambios remotos antes de enviar cambios.
- ¡Usar otro flujo de trabajo!
Recomendaciones
- Hay un repositorio central.- Cada colaborador necesita acceso
para leer y escribir en el repositorio central.
- Se trabaja en ramas de nueva funcionalidad.
- Las ramas son de corta duración.- Es ideal para equipos que practican
entrega continua de software.
Características:
- El desarrollo hecho en una rama puntual debe ser revisado por los colaboradores quienes deberán descubrir defectos y proponer o contribuir con mejoras.
- La revisión de código se hace por medio de Pull Requests.
- Las ramas puntuales se fusionan a la rama master una vez que la funcionalidad esté libre de defectos.
Revision de Código
- Hay por lo menos una rama paralela a master, llamada desarrollo, que siempre permanece abierta.
- Se usan ramas puntuales que nacen de la rama de desarrollo y se fusionan en esta última cuando estén completas.
- La rama de desarrollo no siempre es estable, y cuando lo es se puede fusionar con master.
Caracteristicas:
- Opcionalmente puede haber una rama de liberaciones que vendría a ser una banda intermedia entre desarrollo y master.
- También puede haber una rama de emergencias (hotfix) para acelerar la entrega de código para arreglar defectos críticos.
Mas Características:
Como el uso de ramas puntuales es parte de este flujo de trabajo, se puede crear Pull Requests (peticiones de cambio) para hacer revisión de código.
Revisión de Código
Como la implementación de este flujo de trabajo tiende a ser un poco tediosa, existe una extensión llamada git-flow que facilita la gestión de este flujo.
- https://github.com/nvie/gitflow- http://danielkummer.github.io/git-flow-
cheatsheet/index.es_ES.html
¡Ojo!
- Cada desarrollador tiene un repositorio remoto que es una copia del repositorio original.
- Puedes contribuir a cualquier proyecto de código abierto sin tener permiso para escribir al repositorio original.
Características:
- Si eres dueño de un proyecto de código abierto, cualquier interesado en contribuir a tu proyecto lo puede hacer sin que te conozca.
- Los Pull Requests están enraizados en este flujo de contribución.
- También se puede implementar GitFlow.
Mas Características:
Image source: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow