Guía para contribuir al proyecto

1. Cada task o implementación debe ser gestionada a través de un issue. Este issue tomara un numero, por ejemplo #125.

2. Cada task debe ser asignada a un solo responsable.

3. Para cada task, se debe crear un branch siguiendo la siguiente convención: n-nombre_del_issue, donde n es el numero de la issue. Por ejemplo, para la issue #125 de "Crear usuarios", la rama se llamaría 125-crear_usuarios

git checkout master                  #Una vez hechos todos los commits en nuestra rama, nos pasamos a la rama master

git pull                             #Traemos lo nuevo de master que esta en remoto para actualizar nuestro local

git checkout -b 125-crear_usuarios   #Creamos la nueva rama donde vamos a trabajar

4. Mientras se va trabajando, es recomendable, cuando se logran pequeños pasos, ir haciendo commits sobre la rama en la que estamos trabajando, y pusheando los cambios al servidor:

git status                          #Comprobamos los archivos modificados y si estamos sobre la rama indicada

git add -A                          #Agregamos todos los archivos para ser commiteados

git commit -m "Commit message"      #El mensaje describe lo que hiciste (las comillas ESTÁN incluidas)

git push origin nombre_del_branch   #Coloca los cambios en el repo remoto

5. Una vez finalizado el trabajo y corroborado que funcione, se hace un Pull Request

6. Asignar el Pull Request a un responsable de revisión, que sera encargado de marcar correcciones en caso de que las haya, y una vez que estén solucionadas, será mergeado a master.

Conflictos al crear Pull Request

Cuando queremos fusionar nuestra rama (ya terminada y testeada, lista para entrar en producción) con el master, tenemos que crear un Pull Request, el cual sirve para que otra persona revise lo que se hizo en busca de errores y dé el visto bueno para hacer el merge. En algunos casos, suele pasar que hay inconsistencias entre nuestra rama y master. De ser así, tenemos que seguir los siguientes pasos:

git checkout master       #Realizamos los commits de todo lo que tenemos en nuestra rama y nos pasamos a master

git pull                  #Traemos lo nuevo de master que esta en remoto para actualizar nuestro local

git checkout 23-mi_rama   #Volvemos a la rama conflictiva de nuestro local

git merge master          #La fusionamos con nuestro master de local (ya actualizado con remoto)

Luego de esto, van a aparecer todos los archivos en los que existen conflictos. Lo que queda por hacer es abrirlos y solucionar manualmente cada inconveniente.

Para orientar al desarrollador, Git establece una metodología donde agrega a nuestro código la siguiente comparación:

def hello
<<<<<<< HEAD
  puts 'hola world'
=======
  puts 'hello mundo'
>>>>>>> master
end

hello()

Esto significa: HEAD nos muestra nuestros cambios locales y master los que traemos del repositorio remoto. Sólo nos queda unificar ese código problemático y subir los cambios como ya sabemos.

Redacción de Commits

Cuando se realiza un commit, en su mensaje se debe describir lo que se hizo sin repetir datos que Git mismo ya nos pueda brindar. ¿Qué quiere decir esto? Que en la redacción debemos concentrarnos en el qué y no en el cómo, ya que este último lo podemos ver detallado en los registros que lleva Git ante cada cambio realizado.

La idea se centra en que al leer el mensaje después de algún tiempo, podamos interpretar rápidamente que se hizo.

A modo de ejemplo, para realizar un commit de una tarea en donde había que agregar una vista para presentar un listado de productos, hacemos:

git commit -m "Add products list view"                                             #CORRECTO

git commit -m "Add html file (products-list-view.html) to display products list"   #INCORRECTO