El año pasado, que me mandaron a la reserva nacional de talentos, el jefe de sistemas de la delegación, me dijo que quería participar en el desarrollo del cuadro de mando. Muchos querían participar, más que nada para colgarse la medalla.

En ese momento se me ocurrió usar Git para controlar las contribuciones que ellos pudieran hacer al código. Al final, por lo avanzado del desarrollo de la versión, no implementé el sistema de control de versiones. Por otro lado, nadie ha hecho la mínima contribución al código.

Pero con el proyecto de la nueva versión del Cuadro de Mando Integral 2014, tengo una pequeña oportunidad de aplicar las mejores prácticas de desarrollo web a este proyecto y empezar a reescribir el código de forma que sea más profesional y más fácil de mantener.

Lo primero que tengo que hacer entonces es crear este repositorio de control de versiones. Y aprender a usarlo.

Instalación de GitHub

Lo primero que tenemos que hacer es crear una cuenta en GitHub y descargar el programa GitHub para Mac o el que corresponda a tu plataforma.

Con este programa podemos hacer muchas operaciones con un solo clicl, por ejemplo, podemos:

• Clonar repositorios
• Buscar en el historial
• Enviar cambios
• Compartir código en github.com
• Y mucho más.

Definiciones

Es bueno también entender algunas definiciones importantes cuando hablamos de GitHub, para que todos estemos en el mismo canal.

Branch o Rama

Una rama es una versión paralela de un repositorio. Está contenida dentro del repositorio pero no afecta la rama primaria o master lo que nos permite trabajar libremente si afectar con nuestros cambios la versión en producción. Cuando los cambios están listos, puedez unir esta rama en la master para publicar los cambios.

Clonar

Clonar es hacer una copia de un repositorio que reside en nuestra computadora, en lugar de algún sitio web. Un clon es dicha copia. Con un clon podemos editar el código fuente en nuestro editor preferido y usar Git para que lleve un registro de los cambios que hemos hecho sin necesidad de estar en línea. De esto modo, los cambios se sincronizarán con la versión remota cuando estemos en línea.

Commit o Revisión

Un commit o revisión es un cambio individual a un archivo (o a un conjunto de archivos). Es como cuando guardas un archivo, pero en Git, cada vez que guardas se crea un identificador único (también llamado firma “SHA” o huella “hash”) que permite llevar un registro de los cambios que se han realizado y del autor de los mismo. Los commits usualmente tienen un peqieño mensaje que explica el motivo del cambio realizado.

Fetch

Hacer un fetch o fetching se refiere a obtener los cambios más recientes del repositorio en límea sin mezclarlos con el código en la rama local para poder compararlos.L

Pull

Hacer pull se refiere a traer los cambios y unirlos a la rama local. Por ejemplo, si alguien edita un archivo remoto y tu estás trabajando en él, cuando hagas el pull verás esos cambios en tu copia local.

Pull Request

Las pull request son cambios que los usuarios proponen enviándolos a los repositorios y que los colaboradores pueden aceptar o rechazar. Al igual que los problemas o issues, cada pull request tiene su propio foro de discursión.

Creación del Repositorio

Repositorio Local

Vamos a crear entonces nuestro proyecto. Nos vamos a la carpeta de Proyectos y creamos el directorio cmi:

namespace:Proyectos javier$ mkdir cmi
namespace:Proyectos javier$ cd cmi

Y dentro de este subdirectorio, creamos el nuevo repositorio con git:

namespace:cmi javier$ git init
Initialized empty Git repository in /Users/javier/Documents/Proyectos/cmi/.git/

Repositorio en GitHub

Como les decía este proyecto será manejado en GitHub, por lo que desde mi cuenta en GitHun, creo un repositorio y creo el archivo README.md para facilitar la clonación en mi computadora.

Una vez listo nuestro repositorio en GitHub, podemos clonarlo para trabajar de forma local usando el comando git clone,

namespace:Proyectos javier$ git clone https://github.com/jstoledano/cmi.git
Cloning into 'cmi'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

Ahora, para seguir practicando con nuestro repositorio vamos a editar el archivo README.md con una explicación de que contiene el proyecto para poder hacer un commit y un push.

El archivo README.md utiliza la sintaxis de Markdown y es muy fácil de aprender. Así se ve el texto en este archivo:

# Cuadro de Mando Integral 2014

>Cuadro de Mando Integral para la Junta Local en Tlaxcala

El Cuadro de Mando Integral es un complemento del Sistema de Gestión de la Calidad (SGC) que tiene como facilitar la implementación y mantenimiento del SGC, incorporando las siguientes funcionalidades:

- Gestión de evidencias de metas del Servicio Profesional
- Control de documentos
- Control de registros
- Competencias del personal
- Gestión de Indicadores
- Gestión de Avisos

Esta información esta disponible en la red interna de modo que todos los usuarios pueden consultarla simplemente escribiendo la dirección en un navegador: [http://10.69.0.68](http://10.69.0.68)

Envío de cambios al repositorio

Ahora debemos registrar los cambios usando el comando add:

namespace:cmi javier$ git add README.md

El siguiente paso es hacer commit, para crear la revisión:

namespace:cmi javier$ git commit -m "Registro inicial del proyecto"
[master 385b261] Registro inicial del proyecto
 1 file changed, 14 insertions(+), 4 deletions(-)
 rewrite README.md (98%)

Como pueden ver, agregamos un mensaje para aclarar de que va la actualización usando el parámetro -m.

Por último debemos enviar esta revisión al repositorio remoto, usando el comando push:

namespace:cmi javier$ git push origin master
Username for 'https://github.com': jstoledano
Password for 'https://jstoledano@github.com':
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 628 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/jstoledano/cmi.git
   b49f11f..385b261  master -> master

La estructura del proyecto

Ahora vamos a continuar con la actalización el proyecto, estableciendo el entorno virtual y la estructura básica. Primero creamos el entorno virtual,

namespace:cmi javier$ mkvirtualenv cmi
New python executable in cmi/bin/python
Installing Setuptools..............................................................................................................................................................................................................................done.
Installing Pip.....................................................................................................................................................................................................................................................................................................................................done.

Instalamos Django, usando el comando pip, con el entorno activado, que se lee entre paréntesis.

(cmi)namespace:cmi javier$ pip install django
Downloading/unpacking django
  Downloading Django-1.6.2.tar.gz (6.6MB): 6.6MB downloaded
  Running setup.py egg_info for package django

    warning: no previously-included files matching '__pycache__' found under directory '*'
    warning: no previously-included files matching '*.py[co]' found under directory '*'
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.7/django-admin.py from 644 to 755

    warning: no previously-included files matching '__pycache__' found under directory '*'
    warning: no previously-included files matching '*.py[co]' found under directory '*'
    changing mode of /Users/javier/entornos/cmi/bin/django-admin.py to 755
Successfully installed django
Cleaning up...

Podemos crear nuestro proyecto junto con la primera aplicación y definir su estructura:

(cmi)namespace:cmi javier$ django-admin.py startproject cmi
(cmi)namespace:cmi javier$ cd cmi
(cmi)namespace:cmi javier$ django-admin.py startapp core

Esta es la estructura resultante del proyecto:

Registro de cambios

Vamos a repetir el proceso de control de versiones, enviando estos cambios a la rama master de nuestro repositorio, siguiendo los mismo pasos que vimos al principio:

1. Registrar el cambio con add
2. Enviar los cambios al HEAD con commit
3. Enviar la revisión a la rama maestra con push

(cmi)namespace:cmi javier$ git add .
(cmi)namespace:cmi javier$ git commit -m "Creacion del proyecto con Python"
[master 627d8aa] Creacion del proyecto con Python
8 files changed, 130 insertions(+)
create mode 100644 cmi/cmi/__init__.py
create mode 100644 cmi/cmi/settings.py
create mode 100644 cmi/cmi/urls.py
create mode 100644 cmi/cmi/wsgi.py
create mode 100644 cmi/core/__init__.py
create mode 100644 cmi/core/admin.py
create mode 100644 cmi/core/models.py
create mode 100644 cmi/core/tests.py
create mode 100644 cmi/core/views.py
create mode 100644 cmi/manage.py
(cmi)namespace:cmi javier$ git push origin master
Counting objects: 15, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (14/14), 2.45 KiB, done.
Total 14 (delta 0), reused 0 (delta 0)
To https://github.com/jstoledano/cmi.git
385b261..627d8aa  master -> master

Como pueden ver, ahora use git add . para enviar todos los cambios que se encuentren a partir del directorio del proyecto, porque todos los cambios forman parte de la misma revisión.

Esta es la nueva forma de trabajar con Git. Más adelante, conform avence el proyecto veremos otras funciones del control de versiones y como se usan en el cuadro de mando.