Cómo Gestionar Proyectos Python con Git

Siempre que comenzamos un Proyecto Python es recomendable emplear un Sistema de Control de Versiones (VCS por sus siglas en Inglés), pues esto nos facilitará el trabajo y nos ahorrará infinidad de dolores de cabeza. Si se trata además, de un proyecto Open Source, donde colaboran varios desarrolladores, diseñadores gráficos, redactores, etc., el uso de un VCS es imprescindible. En esta entrada vamos a presentarles un breve tutorial para la gestión de Proyectos Python con el empleo del VCS Git y de GitHub. Este tutorial es el resultado de nuestra experiencia práctica y está influenciado por las ideas de Vincent Driessen, que podrán encontrar en su Blog Post titulado: A successful Git branching model”, y que además, recomendamos leer detenidamente.

Los Pasos a Seguir

El procedimiento que les presentamos resume el flujo de trabajo elemental para mantener y gestionar un Proyecto Python con Git/GitHub. Pretendemos que este procedimiento les sirva como una guía rápida (un “Mata Burro”, en buen cubano) y agilice este proceso. Comenzamos por el paso cero por supuesto:

0.- Comenzamos un nuevo Proyecto Python definiendo un directorio raíz de igual nombre que nuestro proyecto. Pondremos dentro de este directorio nuestros paquetes, módulos, scripts y resto de los archivos que componen nuestro primer borrador de proyecto.

1.- Creamos un repositorio Git con dos ramas principales: master y develop. Estas ramas estarán presentes durante toda la vida del proyecto, son ramas que podríamos llamar permanentes. En la rama master solo mantendremos las liberaciones del proyecto, mientras que la rama develop será la protagonista principal de todo el desarrollo del proyecto. Podemos pensar en develop como el borrador de un documento y en master como el documento final ya terminado, que da comienzo a un nuevo ciclo de actualizaciones, correcciones, modificaciones, adiciones y mejoras.

  1. Creamos un repositorio Git inicial, con la rama master por defecto, dentro de nuestro directorio raíz

    $ cd myproject

    $ git init

  2. Hacemos nuestro primer commit en la rama master para salvar todos los archivos del proyecto inicial

    $ git commit -a -m 'First commit'

  3. Creamos una rama develop derivada de master, en esta rama realizaremos todo el proceso de desarrollo

    $ git branch develop master

2.- Creamos nuestro repositorio remoto en GitHub.com, para lo cual debemos registrarnos en este sitio y tener claras nuestras credenciales de usuario.

  1. Añadimos el repositorio remoto como “origen” de nuestro repositorio local

    $ git remote add origin https://github.com/myaccount/myproject.git

  2. Hacemos un push al repositorio remoto para subir el contenido de nuestras dos ramas: master y develop

    $ git push origin master

    $ git checkout develop

    $ git push -u origin develop

Con esto ya teneos sincronizado nuestro repositorio remoto con el local, ahora a continuar el desarrollo.

3.- Definiremos para el desarrollo, tres tipos de ramas temporales: feature-* para nuevas características, release-* para preparar las liberaciones, hotfix-* para corregir errores (bugs) críticos que se presenten en producción. En cada caso sustituiremos el asterisco “*” por un nombre identificativo del objetivo de la rama. En el caso de las ramas release-*, sustituimos el asterisco con el número de versión correspondiente.

4.- Las ramas feature-* se derivan de develop y luego de terminado el trabajo, se incorporan los cambios (merge) a la rama develop. En estas ramas se concentra el trabajo encaminado a agregar nuevas funcionalidades y características al proyecto. Son ramas temporales, su tiempo de vida se limita al tiempo necesario para desarrollar, probar y liberar la nueva funcionalidad o características que queremos incorporar al proyecto. En algunas ocasiones, estas ramas son eliminadas sin que se concrete la incorporación de la característica que le dio origen a la rama. Esto puede deberse al surgimiento de problemas y situaciones que impiden o dificultan el desarrollo de la nueva característica y se decide prescindir de esta, en bien del proyecto como un todo.

  1. Creamos una rama feature-*

    $ git checkout -b feature-new develop

  2. Trabajamos en la nueva característica y cuando esté lista, hacemos commit

    $ git commit -a -m 'Commit message for added feature'

  3. Incorporamos los cambios a la rama develop

    $ git checkout develop

    $ git merge --no-ff feature-new

  4. Eliminamos la rama feature-* que ya no es necesaria

    $ git branch -d feature-new

  5. Hacemos un push al origen en el repositorio remoto

    $ git push origin develop

5.- Las ramas release-* se derivan de develop y una vez concluido el desarrollo y listo el proyecto para una nueva liberación, se incorporan los cambios (merge) a las ramas master y develop. Son ramas temporales, que se crean con el fin de poner a punto el proyecto, para su liberación final.

  1. Creamos una rama release-* cuando la rama develop está casi lista para liberación y ya no se van a incorporar nuevas características

    $ git checkout -b release-version_number develop

  2. Actualizamos el número de versión del proyecto y hacemos commit

    $ git commit -a -m 'Bumping version x.x'

  3. Trabajamos en el código y demás archivos del proyecto para pulir detalles y alistar la liberación. Cuando todo esté listo, hacemos commit

    $ git commit -a -m 'Commit message for releasing project'

  4. Incorporamos los cambios a la rama develop

    $ git checkout develop

    $ git merge --no-ff release-version_number

  5. Resolvemos los posibles conflictos que puedan surgir con la rama develop y hacemos commit

  6. Incorporamos los cambios a la rama master

    $ git checkout master

    $ git merge --no-ff release-version_number

  7. Creamos una etiqueta (tag) de versión, para mantener la historia del proyecto

    $ git tag -a version_number

  8. Eliminamos la rama release-*

    $ git branch -d release-version_number

  9. Hacemos push de las ramas master y develop al origen remoto

  10. Empaquetamos el proyecto para distribución

6.- Las ramas hotfix-* derivan de master e incorporan sus cambios (merge) a las ramas master, develop y release-*, si existe esta última. Estas ramas se crean cuando surgen errores graves (bugs) en el proyecto, que dificultan sus explotación en producción y se eliminan una vez que resolvemos el error y logramos el funcionamiento estable del proyecto.

  1. Creamos una rama hotfix-* cuando aparece un error en producción

    $ git checkout -b hotfix-version_number.1 master

  2. Actulizamos el número de versión del proyecto y hacemos commit

    $ git commit -a -m 'Bumping version x.x.1'

  3. Trabajamos en la corrección del error y una vez resuelto el problema y probado el código, hacemos commit

    $ git commit -a -m 'Commit message for bug fixing'

  4. Incorporamos los cambios a la rama develop (y a release-* si existe)

    $ git checkout develop

  $ git merge --no-ff hotfix-version_number.1

  1. Resolvemos los posibles conflictos que puedan surgir con la rama develop/release-* y hacemos commit

  2. Incorporamos los cambios a la rama master

    $ git checkout master

    $ git merge --no-ff hotfix-version_number.1

  3. Creamos una etiqueta (tag) de versión, para mantener la historia del proyecto

    $ git tag -a version_number.1

  4. Eliminamos la rama hotfix-*

    $ git branch -d hotfix-version_number.1

  5. Hacemos push de las ramas master y develop al origen remoto

  6. Empaquetamos el proyecto para distribución

Consideraciones Finales

Finalmente debemos hacer notar varia cuestiones relacionadas con el procedimiento anterior. En primer lugar, asumimos que se trata de un proyecto unipersonal, es decir, un proyecto desarrollado por un único programador, que está en control y es responsable de todo lo que sucede en el proyecto. En este supuesto, la existencia de un repositorio remoto nos servirá únicamente como una copia de seguridad de nuestro proyecto local. Si queremos gestionar un proyecto con varios desarrolladores, habría que añadir algunas políticas de acceso y definir una jerarquía de equipo para evitar que el proyecto se convierta en un caos. El centro del proyecto pasaría a ser el repositorio remoto, en lugar del local y habría que variar algunos detalles en el flujo de trabajo.

Lecturas Recomendadas

Para profundizar en el estudio del Sistema de Control de Versiones Git recomendamos la lectura del libro Pro Git2da Edición, por Scott Chacon y Ben Straub, publicado por la Editorial Apress.

Bien, esto es todo por ahora, si este artículo te resultó interesante y/o útil, compártelo para que otros también puedan acceder a él. Déjanos tus comentarios y podremos mejorar nuestros contenidos.

Gracias de antemano,

lpozo

6 comentarios

Ir al formulario de comentarios

    • Mr Yaz on 22 mayo, 2018 at 5:08 pm

    Amigo muy interesante su tutorial, verá estoy interesado en iniciarme en el mundo Python, lo encontré muy intersante como leguaje de programación desde que leí sobre él hace ya algún tiempo, pero como todo cubano que no tiene internet me es dificil conseguir tutoriales para iniciarme en el tema. Entonces es que yo le pido si no le es molestia algún canal de comunicación con Usted ya sea por e-mail para ver si me puede ayudar con el tema y algunos materiales de estudio.
    Saludos.

    1. Hola, @Mr Yaz. Primeramente decirle que me algra mucho que le haya resultado interesante el Tutorial, esperamos le resulte útil y sobre todo que le facilite las cosas para continuar aprendiendo Python.
      Le estoy escribiendo un correo a su dirección para que tenga mi contacto y poder intercambiar materiales. Creo que lo primero es que me diga cuáles son sus intereses para a partir de ahí enviarle algunas cosas.
      saludos,
      lpozo

    • whoami on 27 mayo, 2018 at 3:26 am

    Hola Leodanis de nuevo agradecerte por mantener el blog limpo y claro, quiero decirte que en mi página voy a empezar a hacer tutoriales de python pero x videos, algo que también te aconsejaría (usas kali linux para grabar nada más desde un Live CD y puedes grabar hasta 15 min x menos de 5MB) además, revisa tu correo que te escribí y luego seguiremos en contacto. Un saludo compa

    1. Buenos días @cepaj. Muchas gracias por tus palabras de elogio con respecto al Blog, me alegro mucho de que seas nuestro seguidor. Ya recibí tu correo, luego te responderé, en cuanto tenga un tiempo para conectarme. Te adelanto que tengo varios libros sobre el tema central del libro que me pides, pero, lamentablemente no tengo ese título específico. Te enviaré un listado de los libros que tengo y luego me dices cual te interesa. En cuanto a los videos, tomo nota de tu sugerencia, solo que acá en Reflejos creo que se me va a dificultar un poco el tema por la velocidad de conexión y la capacidad de almacenamiento.
      un saludo y gracias nuevamente,
      lpozo
      PD: Déjame la dirección de tu página para poder visitarla.

    • cepaj on 28 mayo, 2018 at 5:42 pm

    Q vá men, si me cerraron la página !!!!!!!!!!!! jejeje espero entonces tu respuesta x correo y sinceramente si pueds hacerme el favor mándame todos esos libros poco a poco, yo sé q puede ser difícil pero si te resulta de algo yo te puedo dar mi cuenta de intranet (fíjate voy a confiar en ti) para que me los mandes un saludo

    1. Bueno, siento mucho que te hayan cerrado tu página hermano. No te preocupes, yo te envío los libros poco a poco, eso es un hecho. Te los enviaré desde mi correo nauta.
      saludos,
      lpozo

Los comentarios han sido desactivados.