(→Tipos de modificaciones) |
(→Referencias) |
||
(7 revisiones intermedias por el mismo usuario no mostrado) | |||
Línea 1: | Línea 1: | ||
+ | ==Documentación== | ||
+ | * [[Git]] | ||
+ | * [[Cómo usar SVN]] | ||
==Generales== | ==Generales== | ||
Línea 115: | Línea 118: | ||
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. | 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<ref name= | + | Este workflow es básicamente una copia del de Diaspora<ref name=Diaspora/> |
[[Imagen:Feature y develop.png|right]] | [[Imagen:Feature y develop.png|right]] | ||
Línea 142: | Línea 145: | ||
git pull upstream 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 | + | 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 checkout feature-compatilibidad_ubuntu | ||
git rebase develop | git rebase develop | ||
Línea 164: | Línea 167: | ||
==Referencias== | ==Referencias== | ||
<references/> | <references/> | ||
+ | * Migración de repositorios SVN a GIT: http://viget.com/extend/effectively-using-git-with-subversion | ||
+ | |||
+ | [[Categoría:SVN]] | ||
+ | [[Categoría:Git]] | ||
+ | [[Categoría:Desarrollo]] |
Todos los cambios deberán ser subidos periódicamente a un VCS (Version contro system).
Actualmente tenemos distintos VCS:
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).
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).
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".
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):
Luego opcionalmente pueden existir los siguientes branch:
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.
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.
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)
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.
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]
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