Lihuen
RSSRSS AtomAtom

Diferencia entre revisiones de «Workflow Git/SVN»

(Para desarrolladores externos)
(Referencias)
Línea 164: Línea 164:
 
==Referencias==
 
==Referencias==
 
<references/>
 
<references/>
 +
 +
[[Categoría:SVN|Git|Desarrollo]]

Revisión de 11:12 30 sep 2013

Generales

Todos los cambios deberán ser subidos perió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 repositorios pú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 disruptivos pueden 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 versiones originales 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 rama puede 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:

git checkout 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 checkout master
git merge develop
git tag 2.0
git 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 borrar ese branch.

Branching model (Vincent Driessen)

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 el desarrolladore deberá hacer un merge de los cambios de develop en master y luego crear el tag.

Para crear un repositorio nuevo

Develop y master.png

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 proyecto en Markdown [2] o en texto plano:

vi README.md
git add README.md

4. Opcionalmente agregar el código inicial (por ejemplo si está basado en un paquete ya existente):

cp -r /tmp/codigo/* .
git add *

5. Primer commit:

git commit -m "Initial commit"
git push origin master

6. Crear branch develop y posicionarse en ese branch:

git branch develop
git checkout develop
git push -u origin develop # El -u solo es necesario en el primer push

7. Hacer todas las modificaciones y commits que sean necesarios siempre en el branch develop (esto son días, semanas o hasta meses de trabajo). Cuando hagamos push, será:

git push

o

git push origin develop

8. Cuando los cambios estén listos para ser publicados (es decir que fueron probados y en el caso de paquetes como lihuenconfig se generaron ISOs y se probó que todos los cambios funcionan), los podemos mergear con master:

git checkout master
git merge develop

9. Y podemos crear el tag correspondiente, para luego volver al branch develop:

git tag 0.1
git checkout develop
git push origin master # Notar que esta vez subimos master (deberíamos hacer push de develop también)


Para descargar un repositorio existente

1. Lo clonamos y pasamos al branch de desarrollo:

git clone git@gitlab.linti.unlp.edu.ar:software-libre/repo_existente.git
cd repo_existente
git checkout develop

2. Seguir los pasos 7 en adelante del workflow anterior.

Para desarrolladores externos

El esquema que usaremos para desarrolladores externos será el uso de "Pull requests" en GitHub para desarrolladores externos al laboratorio y de "Merge requests" en GitLab (que es lo mismo que el Pull request) para desarrolladores internos.

Este workflow es básicamente una copia del de Diaspora[2]

Feature y develop.png

El workflow en este caso implica crear un fork del repositorio (usando la interfaz de GitHub o la de GitLab según corresponda) y un "feature branch". Entonces luego de hacer el fork: 1. Clonar el fork que hicimos:

git clone git@github.com:[you]/diaspora.git
cd diaspora

2. Es altamente recomendable agregar un remoto que haga referencia al repositorio original, de esta manera mantenemos actualizado nuestro fork:

git remote add upstream git://github.com/diaspora/diaspora.git

3. Pasar branch "develop" y estando en el mismo creamos el branch para el "feature" o "hotfix" en el que se trabajará:

git branch feature-compatibilidad_ubuntu

4. Hacer cambios y un commit con los mismos:

git add archivo_nuevo
git add archivo_modificado
git commit -m "Mensaje de commit"

5. Subir los cambios al fork creado:

git push origin feature-compatibilidad_ubuntu

6. Actualizar el upstream

git fetch
git checkout develop
git pull upstream develop

7. Volvear al "feature" y basar los cambios del feature en la última revisión de "develop" para que el branch "feature" no diverja demasiado de "develop":

git checkout feature-compatilibidad_ubuntu
git rebase develop

8. Repetir 4 a 7 hasta terminar el desarrollo.

9. En el caso de los paquetes .deb editar debian/changelog describiendo el cambio, en otros casos editar Changelog o Changelog.md.

10. Basar "develop" en el "feature branch":

git rebase develop feature-compatibilidad_ubuntu

11. Subir los cambios (todos los branches, pero especialmente develop)

git push origin develop

12. Abrir un pull request (o merge request)

13. Cuando se acepte el pull/merge request se puede borrar el feature branch:

git checkout develop
git branch -d feature-compatibilidad_ubuntu

Referencias

  1. http://nvie.com/posts/a-successful-git-branching-model/
  2. 2,0 2,1 https://wiki.diasporafoundation.org/Git_Workflow#Branching_model