Github IV: Ramas

Volvemos con los tutoriales sobre Github; en este caso vamos a tratar las ramas parte muy importante a la hora de desarrollar proyectos donde participen varias personas y para poder organizar mejor las versiones de nuestros proyectos. Es por esto que es importante saber como funcionan las ramas.

Para poder entender mejor como funcionan las ramas, supongamos que estamos trabajando en un proyecto varias personas y necesitamos escribir en el mismo fichero una funcionalidad. La primera persona, escribe en el fichero y realiza la operación push al repositorio; cuando la segunda persona intenta escribir, le salta un mensaje de error indicando que hay un conflicto. ¿Esto a qué es debido? ¿Cómo podemos solucionarlo, o podemos minimizar los efectos de este problema?

Es por esto que se utilizan ramas; las ramas son punteros a un commit que podemos utilizar para poder realizar un desarrollo sin influir al resto de personas que están en el desarrollo; como puede ser una funcionalidad nueva o una nueva versión.

Para entender mejor como funcionan las ramas, vamos a mostrar el siguiente esquema.

Captura_de_pantalla_2015-06-30_a_las_9.44.51

Como podemos ver en el esquema la rama master es un puntero que apunta al commit 2(C2); si creáramos una nueva rama podemos hacer commits en esta sin interferir en la rama master.

Captura_de_pantalla_2015-06-30_a_las_9.46.05

Por defecto todos los repositorios tienen una rama desde la cual parten todas. Esta rama es la rama master y es la rama principal del proyecto. Por defecto se realizan los commits a esta rama. Pero podemos crear una nueva Rama.

Lo primero que aprenderemos es a utilizar la aplicación de github para poder manejar nuestras ramas. Para ello, podemos utilizar los botones que aparecen en la barra superior, para crear o cambiar de rama rápidamente.

Captura de pantalla 2015-10-08 a las 21.20.12

Veamos un ejemplo para ver como crear y manejar ramas. Supongamos que tenemos un fichero de texto con un contenido subido a nuestro repositorio.(Por ejemplo podemos usar nuestro repositorio de ejemplo Github 101) Por defecto, nos encontraremos en la rama master.

Captura de pantalla 2015-10-08 a las 21.24.34

Como podemos ver en la anterior figura, tenemos un pequeño archivo .ino que hemos subido en un commit anterior. Queremos crear una nueva funcionalidad, y por lo tanto crearemos una nueva rama para realizarla. Por ello pulsamos el botón de new Branch e introducimos un nuevo nombre; supongamos que la nueva rama es la versión 1.0.1; por lo que la llamaremos v1.0.1.

Captura de pantalla 2015-10-08 a las 21.28.03

Al crear la nueva rama, observaremos que no hay cambios recientes ya que acabamos de crear esta. Seguidamente introduciremos cambios en el fichero .ino; por ejemplo añadimos un comentario //V 1.0.1 y guardamos los datos; observaremos que se nos indica de hacer commit en la aplicación de github.

Al realizar el commit se realizará en dicha rama v1.0.1 y no en la rama master. vamos a cambiar de rama y observar que el fichero modifica su contenido puesto que hay cambios en las ramas. Para cambiar de rama utilizaremos el botón superior que hemos mostrado anteriormente.

Con esto podemos tener separados los distintos desarrollos sin interferir en la propio proyecto o que se vuelva inestable. Sin embargo, ¿Qué ocurre cuando terminamos el desarrollo y queremos añadir la funcionalidad al proyecto estable? Pues que tenemos que hacer una operación merge. Para realizar una operación merge, seleccionaremos la rama a la cual queremos llevar los cambios y usaremos la opción compare para seleccionar la rama origen de los datos; una vez hecho esto, haremos click en el botón update from v1.0.1.

Captura de pantalla 2015-10-08 a las 21.39.03

Al realizar el merge, pueden ocurrir conflictos pero ya no interferirá durante el desarrollo.

Por último, indicar las buenas prácticas a la hora de realizar un proyecto; ya que es recomendable utilizar un esquema de ramas para poder tener un mejor control de las versiones; se recomiendan mínimo 4 ramas.

  • Una rama para realizar el desarrollo desde la cual pueden partir las nuevas funcionalidades
  • Una rama para cada nueva funcionalidad que parta de la anterior.
  • Una rama para testeo de las funcionalidades que ya estén desarrolladas.
  • La rama principal o master que contiene la versión estable.

Sin más os dejamos una presentación donde explican como utilizar Git y el resto de funcionalidad de este; además de un enlace al libro oficial de Git para aprender más sobre Git y las Ramas.

  1. http://slides.com/zerasul/git
  2. https://git-scm.com/book/es/v1

 

Be the first to comment on "Github IV: Ramas"

Deja un comentario.

Tu dirección de correo no será publicada.


*


*