Trabajando con el control de versiones GIT¶
Git es un sistema de control de versiones o SCM (en inglés Source Code Management). El control de versiones es un sistema que registra los cambios realizados sobre un archivo de código fuente o un conjunto de archivos de código fuente a lo largo del tiempo, de modo que en un futuro se puedan recuperar versiones específicas más adelante. Git permite el versionado de código fuente tal como:
- HTML / CSS / Javascript
- PHP, .NET, Ruby, ASP, Python, entre otros
- Archivos de configuración
- Documentación
… y un largo etc
¿Qué aporta git?¶
- Auditoría del código: saber quién ha tocado qué y cuándo.
- Control sobre cómo ha cambiado nuestro proyecto con el paso del tiempo.
- Volver hacia atrás de una forma rápida.
- Control de versiones a través de etiquetas.
- Mejora nuestra capacidad de trabajar en equipo.
Buenas prácticas¶
Cada desarrollador o equipo de desarrollo puede hacer uso de Git de la forma que le parezca conveniente. Sin embargo una buena práctica es la siguiente:
Se deben utilizar 4 tipos de ramas: Master, Development, Features, y Hotfix.
Produccion¶
Es la rama principal. Contiene el repositorio que se encuentra publicado en producción, por lo que debe estar siempre estable.
Release¶
Es la rama de Entrenamiento. Contiene el repositorio que contiene los desarrollos que serán evaluados con data real (1 día de desfase con respecto a producción) sin que afecte producción.
QA¶
Es la rama de QA. Contiene el repositorio que contiene los desarrollos que serán revisados en QA antes de ser habilitados para producción.
Desarrollo¶
Es la rama de desarrollo inestable, todas las nuevas funcionalidades propuestas en las peticiones del sistema de proyectos (Redmine) se deben integrar en esta rama. Una vez que se verifique la funcionalidad, se puede hacer un merge de desarrollo sobre la rama Release.
Tareas asignadas (tarea/###)¶
Cada nueva funcionalidad se debe realizar en una rama nueva, específica para esa funcionalidad. Una vez que la funcionalidad se encuentre realizada, se hace un merge en desarrollo, donde se integrará con las demás funcionalidades.
Iniciando un proyecto¶
- Iniciar el proyecto
git init
- Link al repositorio de INDAP
git remote add origin sistemaunico@proyectos.indap.cl:~/git
- Descargar las cabeceras de las tareas desde el repositorio
git fetch # git fetch nos permite descargar el estado actual de todas las ramas del repositorio con lo cual no es necesario crear ninguna rama ya existente git checkout produccion #para cambiarnos a la rama productiva git checkout release #para cambiarnos a la rama de release git checkout qa #para cambiarnos a la rama de QA git checkout desarrollo #para cambiarnos a la rama de desarrollo
- Todos los nuevos proyectos serán creados a partir de Produccion con el fin de tener la ultima actualización posible
git checkout produccion git checkout -b Proyecto git checkout -b Proyecto-qa git checkout -b Proyecto-test
- Bajo la rama de Proyecto, se realizaran todas la tareas que se creen en las peticiones de proyectos.indap.cl, por lo tanto cualquier tarea asignada debe poseer su rama
git checkout Proyecto git checkout -b tarea/###
- Realizar los add y commit correspondientes, una vez terminada la tarea cambiar desarrollo y unir con la rama de la tarea con la rama de desarrollo
git add archivo/os git commit -m "comentario" --una vez termina la tarea cambiar a desarrollo git checkout desarrollo git merge tarea/###
- Eliminar rama asociada a la tarea
git branch -d tarea/###
- Cerrar la tarea en peticiones de proyectos.indap.cl
Creación de tareas¶
Para crear tareas lo primero que se debe conocer es si el proyecto esta en producción o en desarrollo, para lo cual se deben seguir las siguientes recomendaciones:
- Tarea desde proyecto en Producción. Estas tareas se crean desde la rama master. (* indica la rama actual donde estoy posicionado)
$ git branch desarrollo entrenamiento master qa * tarea/1111 $ git checkout master $ git checkout -b tarea/nueva-2222 - Tarea desde proyecto en Desarrollo. Estas tareas se crean desde la rama del proyecto. (* indica la rama actual donde estoy posicionado)
$ git branch desarrollo entrenamiento master proyecto_XXX qa * tarea/1111 $ git checkout proyecto_XXX $ git checkout -b tarea/nueva-2222
Subir cambios¶
Una vez que se termina de realizar cambios en archivos estos deben ser subidos a la tarea, para su posterior mezcla con otras ramas o simplemente para que estos se vean reflejados en el servidor de Desarrollo o QA. A continuación un ejemplo:
$ git status
On branch tarea/XXXX
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: www/css/sig/base.css
modified: www/sirsd_sig_historico_region.js
modified: www/sirsd_sig_rut.php
modified: www/templates/sirsd_sig_historico_region.html
Se debe poner ojo en las lineas que comienzan con [modified:], ya que esta indican el/los archivos que se deben incluir. Seguir el siguiente ejemplo:
$ git add www/css/sig/base.css www/sirsd_sig_historico_region.js www/sirsd_sig_rut.php www/templates/sirsd_sig_historico_region.html
$ git commit -m "comentario de los cambios realizados" [tarea/XXXX 2be6ad5e9] comentario de los cambios realizados 4 files changed, 130 insertions(+), 53 deletions(-)
git push origin tarea/XXXX
password:
Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 2.31 KiB | 0 bytes/s, done.
Total 10 (delta 8), reused 0 (delta 0)
To proyectos.indap.cl:/home/sirsd/git
23f551658..2be6ad5e9 tarea/XXXX -> tarea/XXXX
Mezclando ramas¶
Para mezclar ramas se deben realizar como mínimo los pasos Creación de tareas y Subir cambios.
Las mezclas deben tener un orden que se debe respetar y es el siguiente:- Mezclar hacia proyecto
- Mezclar hacia Desarrollo
- Mezclar hacia QA
- Finalizar mezclando con Master
- Saber en que rama se esta posicionado. (* indica la rama actual donde estoy posicionado)
$ git branch desarrollo entrenamiento master proyecto_xxx qa * tarea/1111 - Cambiarse a la rama con la que se desea mezclar la tarea, esta puede ser la rama del proyecto o rama de desarrollo, qa, proyecto o cualquier otra. Para este ejemplo la rama de desarrollo.
$ git checkout desarrollo
- Descargas ultimos cambio de la rama desarrollo
$ git pull origin desarrollo
- Realizar la mezcla de la tarea/XXXX con la rama donde estamos posicionados.
$ git pull origin tarea/XXXX
- Subir los cambios al repositorio. Para este ejemplo la rama de desarrollo.
$ git push origin desarrollo
Regresando atrás¶
Hubo algún cambio que se subió alguien y que dejó la escoba... es posible regresar en el tiempo y arreglar todo a través de un agujero de gusano.
- Vaya a Suiza al acelerador de partículas
- Aplique sus conocimientos de física moderna
o bien
- Revise hacia donde quiere regresar obteniendo el HASH deseado
git log
- Si tenemos algún clon del proyecto que haya que retornar
git checkout HASH
- Para volver al ultimo commit guardado en una rama
git checkout rama
Resolviendo conflictos de merge¶
Para resolver conflictos en una mezcla que no se ha podido hacer automáticamente (ambos desarrolladores modificaron una misma linea con soluciones distintas) lo que se debe hacer es lo siguiente:
- Esto no llevará todo el pull a cavo quejandose de un conflicto en un merge
git pull origin rama
- Edite la salida resolviendo el conflicto
git mergetool git checkout --ours archivo_conflictivo git checkout --theirs archivo_conflictivo
- Agregue el archivo editado
git add archivo_conflictivo
- Agregue el comentario
git commit -m "resolviendo conflicto con theirs"
- Haga el nuevo PULL sin conflicto
git pull origin rama
- Siga trabajando como siempre
Bibliografía¶
Se recomienda revisar el siguiente link, donde se encuentra una guía completa de como usar GIT.
[[http://git-scm.com/book/es/]]