Workflow Git SVN

SVN
Contenido
• 1 Documentación
• 2 Generales
♦ 2.1 Tipos de modificaciones
◊ 2.1.1 Nuevo esquema
• 3 Workflow en GitLab y GitHub
♦ 3.1 Para desarrolladores del grupo
◊ 3.1.1 Para crear un repositorio nuevo
◊ 3.1.2 Para descargar un repositorio existente
♦ 3.2 Para desarrolladores externos
• 4 Referencias

Documentación
• Git
• Cómo usar SVN

Generales
Todos los cambios deberán ser subidosperiódicamente a un VCS (Version contro system).
Actualmente tenemos distintos VCS:
1. SVN interno
2. Git interno
3. Git interno con gitlab
4. SVN en SourceForge
5. Git en GitHub
La idea es migrar 1 y 2 a 3 (Migración de SVN a Git)
Los repositorios que estén en VCS públicos como 4 y 5 deberán mantenerse sincronizados con los repositorios de gitlab (Sincronización de repositorios
internos con repositoriospúblicos).

Tipos de modificaciones
Por el momento el desarrollo y los bugfix se hacen sobre el branch master en Git y sobre el directorio trunk en SVN. La idea es mover el desarrollo a un
branch develop y mantener en master solamente las versiones a las que se le asignará un tag.
Las modificaciones disruptivas y refactorings requieren la creación de un branch separado, en caso que el branch seaéxitoso se mergea con master (o
trunk).
Las releases (versiones publicadas) se marcan con un tag (en Git los tags son más ligeros y fáciles de manejar por lo cual deberíamos usarlos más).
Nuevo esquema
El nuevo esquema está enfocado a Git y la idea es trabajar sobre un branch "develop", marcar con tags las versiones estables, master siempre
apuntará al último tag. Y además los cambios disruptivospueden llegar a ir en un "feature branch".

Workflow en GitLab y GitHub
Por las características de nuestro proyecto siendo un número chico de desarrolladores y no requieriendo liberar versiones de forma continua propongo
usar el siguiente esquema basado en el modelo de branching sugerido por Vincent Driessen[1] y en la versión adoptada por el proyecto Diaspora[2].
A diferencia de las versionesoriginales de este esquema no consideraremos fundamentales los feature branch, ni el uso de la herramienta git flow,
aunque queda a gusto de los desarrolladores hacer uso de los mismos.
Cada repositorio tendrá al menos 2 branches (Ventajas de usar un branch develop):
• master <- Versiones que fueron testeadas y tienen un tag asignado.
• develop <- Modificaciones en progreso, el contenido de esta ramapuede no funcionar.
Luego opcionalmente pueden existir los siguientes branch:
• feature-* <- Características especiales, por ejemplo 'feature-soporte_efi'
• hotfix-* <- Corrección de bugs, por ejemplo 'hotfix-segfaul_al_abrir'
• release-* <- Últimos comits antes de crear un tag
Los branches feature solamente serán mergeadas con develop y NUNCA con master. Por ejemplo si terminamos una feature:
gitcheckout develop
git merge feature-que_lleve_el_mate
git push origin develop

Se hacen los tests necesarios y si todo funciona bien y el proyecto está listo para ser publicado:
git
git
git
git

checkout master
merge develop
tag 2.0
push origin master

Luego de terminar de trabajar en un branch feature-*, hotfix-* o release-* y de haber elegido mergear o descartar los cambios [1] hay que borrarese
branch.

Para desarrolladores del grupo
Los desarrolladores del grupo Lihuen directamente pueden acceder a: https://gitlab.linti.unlp.edu.ar/groups/software-libre
La idea es crear los nuevos repositorios dentro de ese grupo y que todo el desarrollo se lleve a cabo dentro del mismo (siempre en el branch develop).
Una vez que los cambios están correctamente testeados y listos para taggear eldesarrolladore deberá hacer un merge de los cambios de develop en
master y luego crear el tag.
Para crear un repositorio nuevo

0. Crear el repositorio en la interfaz web de GitLab.
1. Inicializar un nuevo repositorio:
git init

2. Agregar el remote para poder subirlo al servidor:
git add remote origin git@gitlab.linti.unlp.edu.ar:software-libre/repo_nuevo.git

3. Agregar una descripción del...