Git es un sistema de control de versiones descentralizado, a diferencia de SVN que almacena el repositorio en un servidor centralizado, Git crea una copia del repositorio cada vez que alguien descarga el repositorio. En SVN usamos el comando checkout para descargar un repositorio, en Git usamos el comando clone
Sistemas de Control Versiones Descentralizados
Sistemas de Control Versiones Centralizados
El directorio donde se clona un repositorio es llamado nuestro directorio de trabajo o el working directory, este working directory esta relacionado a un branch del repositorio, por defecto el branch que se crea se llama master. Si lo vemos desde el punto de vista de SVN viene siendo el folder trunk. Dado que Git es un repositorio descentralizado, los branches pueden ser locales (local) o remotos (remote). El servidor del cual se clono el repositorio por primera vez se conoce como el origin (el origen).
A diferencia de SVN donde cada revisión tiene un número asociado, Git genera un hash basado en ciertos elementos como lo son: el id del archivo, el id del commit, el id del branch, cada id esta representado de forma hexadecimal.
Ciclo de Trabajo en Git
A diferencia de SVN, todo el trabajo realizado se mantiene en la copia del repositorio local, no se refleja en el servidor hasta que se haga un push al remote branch. El flujo de trabajo en Git se puede definir de la siguiente manera
- Agregando (add) archivos al working directory: Esto le indica a Git que empiece a monitoriar (track) los cambios realizados a este archivo.
- Guardando (commit) los cambios en el local branch del repositorio: Esto le indica a Git que guarde el status actual de todos los cambios realizados en el working directory
- Subir (push) los cambios al remote branch en el origin: Esto le indica a Git que los cambios están listos para ser publicados y ser accedidos por otros colaboradores.
El área donde se realizan los pasos 1 (add) y 2 (commit) es conocido en Git como el staging area, en esta área se puede definir exactamente que archivos y que cambios en el archivo se harán commit, para esto se puede utilizar el comando status.
Git Staging Area
Ciclo de vida de un archivo en Git
Flujo de Desarrollo en Git
Git ofrece la características de definir flujos de trabajos, en la mayoria de los casos, el flujo de trabajo utilizado es en base a branches, usualmente existen dos branches principales, el master y el develop; cualquier otro branch creado será con el propósito de trabajar algún bug o funcionalidad especifica, estos branches se conocen como un feature/topic branches
- Master Branch: Es el branch de producción, este será el branch utilizado para realizar los deployments al servidor de produccón una vez se haya realizado un merge de los cambios con el develop branch.
- Develop Branch: Es el branch utilizado para realizar todo el desarrollo del proyecto, es el puente que sirve entre los feature/topic branches y el master branch.
- Feature/Topic Branches: Son los branches utilizados para resolver algún problema especifico o desarrollar nuevas funcionalidades del sitio sin afectar la versión de desarrollo actual. Una vez este aprobado los cambios, se harán un merge con el develop branch.
Flujo de Desarrollo en base a Master, Develop y Feature/Topic Branches
Resumen de Commandos
- clone: para descargar el repositorio
- add: para agregar archivos al branch local y monitoriar los cambios
- status: para saber cuales son los cambios listos para guardarse en el local branch
- commit: para guardar los cambios en el branch local
- push: para subir los cambios al branch remoto
- pull: para descargar los ultimos cambios del branch remoto y combinarlos en tu branch local de forma inmediata (un merge)
- fetch: para descargar los cambios pero sin combinarlos con tus cambios locales (no hay merge)
Enlaces Externos:
- Manual de Git: http://git-scm.com/book
- Staging Area: http://gitready.com/beginner/2009/01/18/the-staging-area.html
- Git for Begginners: http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide
