GIT
Conceptos básicos
Hay dos tipos de repositorios:
Sistemas centralizados: En estos sistemas hay un servidor que mantiene el repositorio y en el que cada programador mantiene en local únicamente aquellos archivos con los que está trabajando en un momento dado. Ese sistema centralizado es el único lugar donde está todo el código del proyecto de manera completa. Subversion o CVS son sistemas de control de versiones centralizados.
Sistemas distribuidos: En este tipo de sistemas cada uno de los integrantes del equipo mantiene una copia local del repositorio completo. Al disponer de un repositorio local, puedo hacer commit (enviar cambios al sistema de control de versiones) en local, sin necesidad de estar conectado a Internet o cualquier otra red. Git es un sistema de control de versiones distribuido.
Ventajas de GIT
- Autonomía en el desarrollo de cada uno de los componentes del equipo y la posibilidad de continuar trabajando aunque el servidor central de versiones del software se haya caído.
- Capacidad de restaurar el repositorio en cualquier momento con la versión local de cualquier colaborador, dado que cada uno de ellos tiene una copia completa del mismo.
- Git tiene una validación de integridad de los archivos que se verifica y se realiza automáticamente cada vez que hacemos commit. Todo queda reflejado.
Repositorio local
Tu repositorio local está compuesto por tres "árboles" administrados por git. El primero es tu Directorio de trabajo que contiene los archivos, el segundo es el Index que actúa como una zona intermedia, y el último es el HEAD que apunta al último commit realizado.
Comandos
Puedes utilizar la consola de GIT para trabajar sin cliente de visualización.
Cliente de GIT
El programa recomendado para trabajar con GIT es Sourcetree.
Flujo de trabajo de GIT
El flujo de GIT recomendado es Gitflow. Es un flujo de trabajo basado en dos ramas que perduran en el tiempo: master y develop.
Idealmente cualquier cosa que esté en develop será promocionable a master por lo que debe ser una rama estable donde se mezclan todas las nuevas funcionalidades desarrolladas. Aún así, existe el concepto de rama release: rama que parte de develop y que es la candidata a mezclarse en master. Una vez creada, sólo se podrán subir cambios para resolver problemas, no nuevas funcionalidades. Una vez resueltos todos los problemas, la rama release se mezclará en master y develop y desaparecerá. No se mantiene en el tiempo.
La rama master tiene la versión de producción y, si ya en producción se descubren bugs, habrá que realizar hotfix (ramas donde se arreglan errores) que se mezclarán en master de nuevo.
El flujo de desarrollo normal sería: bajarse develop a local, sacar una rama con nombre "feature/feature-name", realizar el desarrollo y pruebas necesarias de la funcionalidad y mergear a develop.
Los cambios se propagarán de develop a master, excepto en el caso de un hotfix, que se mezclará en ambas.