Tutorial básico de Git y GitHub para uso de control de versiones

Este es un Tutorial básico de Git y GitHub para aquellos que venimos de SVN con el objeto de establecer las similitudes para poder a comenzar con este sistema de control de versiones y tener su propio repositorio Git.

Fue entonces, cuando hice un curso de WordPress donde nos explicaron el uso de Git y GitHub. Hasta ahora siempre he utilizado Subversion SVN y sabía de la existencia de Git pero nunca lo había utilizado, por lo que me dispuse a buscar información relativa a este sistema de control de versiones para tener una idea de su funcionamiento. Por ello, recojo los aspectos más básicos que pude aprender para poder recordarlos.

Diferencias entre Git y GitHub

Primero quiero diferenciar qué es Git y GitHub y su forma de funcionamiento. Git es un sistema distribuido al contrario que SVN. Eso quiere decir que SVN está pensado para trabajar en equipo sobre un repositorio, pero Git está pensado para que cada persona tenga su propio repositorio local y suban los cambios a un repositorio remoto de forma que todo el trabajo sea colaborativo y no sea necesario obligar a trabajar directamente sobre el repositorio remoto. El repositorio local de git se llama Git y el repositorio remoto se llama GitHub. Aparte de GitHub hay más repositorios remotos que implementan Git, como puede ser BitBucket. Cada uno ofrece diferentes características: repositorios públicos gratuitos, los privados son de pago, tienen un límite de colaboradores, etc. Habría que analizar cada uno y ver cuál nos interesaría.

Zonas de trabajo y Git Flow

A diferencia de SVN pude aprender que Git dispone de diferentes zonas de trabajo en función de dónde se encuentren los cambios realizados. En nuestro repositorio local tenemos tres zonas diferenciadas:

• Working Directory: Corresponde con nuestro sistema de ficheros en nuestro PC
• Staging area: Es cuando indicamos a Git que reconozca estos ficheros para que comience a controlar sus versiones. los ficheros pasan a este área después de hacer un "Add".
• Local Repo: Es nuestro repositorio local. Los ficheros pasan a este área después de hacer "Commit".
• Remote repo: Es el repositorio remoto. Puede ser otro repositorio Git que tengamos en otro PC o un repositorio en la nube como puede ser GitHub o BitBucker. Aquí será donde se realicen los merge con otros usuarios que colaboren en el proyecto.

Esquema gráfico de las zonas de trabajo y el Git Flow a seguir:

En principio puede parecernos muy familiar a SVN ya que subversion también dispone del comando "Add" y del comando "Commit", por lo que se puede entender que SVN también dispone de esa zona intermedia. Por otro lado, los comandos "Checkout" y "Merge" si puedo ver que son algo distintos en su funcionamiento. En SVN sólo se puede hacer checkout para actualizar tu repositorio local, pero además al hacer un checkout ya tienes los ficheros "commiteados" porque lo pasarían a la primera zona que tiene Git. Como se puede ver, es algo diferente a SVN y hay que saber qué hace cada comando para saber dónde se encuentran los ficheros en un momento dado.

Trabajar con Git y GitHub

Vamos a empezar a trabajar con Git y GitHub. Para ello necesitamos:

• Cuenta creada en GitHub (Crear aquí) o Bitbucket (Crear aquí)
• Instalar Git en local para montar nuestro repositorio local (Descargar aquí)
• Instalar GitHub en local para poder empujar los cambios al repositorio remoto (Descargar aquí)

Una instalado todo el software en nuestro equipo y creada nuestra cuenta de GitHub podemos hacer lo siguiente:

• Podemos trabajar en local y después subirlo a GitHub
• O podemos querer traernos un proyecto existente de Github a nuestro repositorio local

Trabajar en local para subirlo más adelante en GitHub

• Crear el proyecto en local:
  • Creamos una carpeta para el proyecto con los archivos que queremos versionar
  • Dentro de la carpeta ejecutamos los comandos:
    • git init
    • git add .
    • git commit
• Creamos el proyecto en GitHub:
  • fdsfsd
• Vinculamos el repositorio local con el repositorio remoto:
  • git remote add remoto https://github.com/[MI-USUARIO]/[MI-PROYECTO].git
  • git remote -v
• Empujamos los cambios locales al remoto:
  • git push master

Traernos un repositorio remoto a local

• Identificamos la url del proyecto remoto
• Nos vamos a local y hacemos un clone:
  • git clone <url-github>
  • git add <nombre>
  • git commit -m "Mensaje"
  • git push origin master

Control de versiones con Git: Buenas prácticas

Nota.- Este apartado pretende explicar las buenas prácticas de uso para el control de versiones con Git a la hora desarrollar aplicaciones. Me ha parecido tan interesante esta información donde la encontré que he decidido incluirla en este artículo resumen sobre Git. El texto ha sido extraido de aquí.

Existen ciertas buenas prácticas recomendadas para equipos de desarrollo, el cual se suele llamar Git Flow o flujo de trabajo con Git. Esto permite tener un estándar de desarrollo y organizar correctamente el desarrollo de un proyecto para tener una visión todo el tiempo del proceso, el cual es:

Te explico el gráfico:

• Master: Es la rama (branch) que tiene la última versión productiva del código.
• Release: Es la rama que contiene los nuevos features terminados que se van desarrollando para el siguiente lanzamiento (release) de forma que al iniciar uno nuevo puedas descargar todos los anteriores por si tienen alguna dependencia.
• Develop: Es la rama que contiene las características (features) en desarrollo en una iteración, esta rama será posteriormente parte de Release mediante un pull request.
• Feature: Es la rama que contiene el feature en el que estás trabajando personalmente (varios desarrolladores pueden trabajar en un feature), éste debe ser enviado a develop mediante un full request, por lo general aprobado por el líder técnico.
• Hotfix: Es la rama que contiene cambios urgentes sobre master que permiten corregir un bug o resolver un error, éste debe ser enviado a master y se debe notificar a todos los desarrolladores para que puedan actualizar sus ramas.

Herramientas Git

Para esto existen herramientas que permiten simplificar este proceso mediante comandos, por ejemplo git-flow http://danielkummer.github.io/git-flow-cheatsheet/

El cual te provee de los siguientes comandos, los cuales encapsulan los pasos intermedios para seguir el flujo:

git flow init
git flow feature start MYFEATURE
git flow feature finish MYFEATURE
git flow feature publish MYFEATURE
git flow release start RELEASE [BASE]
git flow release publish RELEASE
git flow hotfix start VERSION [BASENAME]
...

Herramientas Git para usuarios avanzados

Adicionalmente a este flujo, Git provee muchas herramientas que permiten mejorar nuestro flujo de trabajo, gestión de código y automatización. Entre ellas puedo destacar:

Git Tree, Git Submodules: Esto permite integrar repositorios de código independientes como parte de uno mayor para evitar repetir archivos, por ejemplo cuando tienes un repositorio para una librería y otro para una aplicación que usa la librería.

CI, Travis, Code Climate: Herramientas de terceros que permiten automatizar revisión de código y ejecución de test lo que facilita la tarea de colaboración al tener siempre definido el status de consistencia del código después de hacer un merge sobre el full request enviado.

Markdown, Pull Request comments, Etiquetas: Son utilidades que en particular pertenecen a Github, Bitbucket o Gitlab el cual permite crear un hilo de conversación sobre los pull request, etiquetar o enlazar un branch, pull request, commit, usuario o comentario y o crear texto enriquecido enriqueciendo el flujo.

Enlaces de interés sobre Git

Os dejo algunos enlaces de interés para saber más sobre el control de versiones con Git y ampliar conocimientos:

• Página oficial de documentación sobre Git: http://git-scm.com/
• Clase gratuita sobre Git de EscuelaIT: https://www.youtube.com/watch?v=NmbqlkLTOSI
• Comandos principales: http://git-scm.com/docs
• Resumen de comandos: github-git-cheat-sheet
• Cómo utilizar git para trabajar en un mismo proyecto en un equipo distribuido: http://es.stackoverflow.com/questions/13562/c%C3%B3mo-utilizar-git-para-trabajar-en-un-mismo-proyecto-en-un-equipo-distribuido

Guardar

Guardar