Workflow de desarrollo en GitHub
GitHub es la plataforma por excelencia de control de versiones y colaboración en tus proyectos de desarrollo. En el post, analizaremos los conceptos clave para un workflow de desarrollo en GitHub. Para trabajar correctamente con los repositories, branches, forks, commits, pull requests y merging.
Antes de empezar con el artículo, deberías conocer los terminologías como branch, merge, repository, issue, workflow, commit, pull, push, master, fork... Si no es así, te invito a conocerlos en GitHub Help.
¿Qué es el control de versiones?
El control de versiones es un sistema que te ayudará a desarrollador, rastrear y administrar cambios en el código de tus proyectos. A medida que crezcan tus proyectos, la necesidad de disponer de un control de versiones es indispensable, especialmente en los proyectos que desarrolles en equipo. Además, puedes trabajar de forma segura utilizando lo que se conoce como branching y merging.
La Branching te permite duplicar el código fuente "repository", con el que podrás hacer cambios de manera segura sin afectar a todo el proyecto. Una vez que hayas revisado los cambios y se haya acordado en equipo, podrás hacer un merge, fusionando la branch en la que estabas trabajando con la ‘master’ para actualizar el código principal de tu proyecto. Si identificas errores, siempre podrás volver al código original, ya que todos los cambios quedan registrados.
¿Qué es Git?
Git y Github no son sinónimos ;)
Git es un sistema de control de versiones opensource creado por Linus Torvalds en 2005. Este software te permite gestionar los cambios y garantizar que todo el código esté disponible para todo tu equipo. Sin embargo, GitHub simplemente es un servicio que aloja tus repositorios en formato Git, con muchas funcionalidades extras que hacen una herramienta indispensable en tu equipo de trabajo. GitHub desde el 2018 es propiedad de Microsoft.
GitHub no es el único proveedor de estos servicios, hay muchos otros como Bitbucket o Gitlab, cada uno con sus características y su idiosincrasia en el Workflow.
Fundamentos para un correcto workflow
Veremos como gestionar tu proyecto desde la propia interfaz web de GitHub. Si sabes como gestionar repositories y Issues, puedes pasar al siguiente apartado, pero si todavía no tienes una cuenta de GitHub, o no conoces todos los pasos, te mostrare como:
Si todavía no tienes cuenta, puedes regístrate aquí.
Creación de un repository
Un repository en GitHub es como la carpeta raíz de tu proyecto. Contiene todos los archivos del proyecto y te permite acceder al historial de revisiones de todos los archivo. Si trabajas en equipo, podrás dar acceso al resto del equipo para que también puedan trabajar en el proyecto.
Veamos como crear un repository:
- En la esquina superior derecha, haz clic en el icono de configuración + y luego en “New repository”
- Pon nombre a tu repository y añade una descripción si es necesario
- Elige entre crear un repository público o privado (el repository público es accesible al mundo)
- Selecciona “Initialize this repository with a README”
- Selecciona el .gitignore que mejor se adapte a tu proyecto. Te ayudará a no publicar información comprometida de tu proyecto, ignorando archivos de configuración con credenciales o información confidencial.
- Haz clic en “Create repository”.
¡Listo! Ya puedes agregar archivos a tu repository.
Creando una Issue
Los issue te permitirán gestionar el proyecto. Está diseñado para discutir las versiones del proyecto y para gestionar la delegación de tareas. Vamos a crear un nuevo Issue:
- En tu repository, seleccione la pestaña “Issue”
- Clic en el botón “New Issue”
- Indica el asunto de tu Issue y añade una descripción clara de tu inquietud
- Haz clic en “Submit new Issue”
Si abres un Issue en un proyecto administrado por otra persona, permanecerá abierto hasta que lo cierre o hasta que el propietario del repository lo cierre.
Asignando una Issue
Para que tu equipo gestione las Issues, necesitan que las asignes, veamos como hacerlo:
- En el lado derecho, en la sección "Assignees", haz clic en el icono de configuración y selecciona a quien creas conveniente.
Cerrar una Issue
Ahora que tienes creado un Issue, puedes cerrarlo:
- Abre el Issue completado y haz clic en “Close issue”
Puedes eliminar un Issue en GitHub, pero siempre es mejor cerrarlo, ya que así quedará como completado.
Workflow de GitHub
Ahora que sabes cómo trabajar con los repositories y los Issues, es hora de ver el Workflow de GitHub. Es un workflow con el que podrás añadir nuevos desarrollos a tu proyecto de forma segura, sin miedo a comprometer tu proyecto. La solución está principalmente en el branching de tu repository.
De forma predeterminada, tu proyecto se aloja en la branch:master; cualquier cambio en el master se actualizará directamente a tu proyecto. Es muy importante revisar bien tus cambios en este punto, porque puede ser peligroso, ya que actualizarás la branch:master.
Cuando necesites modificar tu proyecto para añadir una nueva funcionalidad, arreglar algún bug o lo que creas conveniente, deberías crear una nueva branch en el proyecto. La branch será inicialmente una copia de la branch:master, y cuando apliques cambios se reflejarán sólo en la nueva branch.
Mientras trabajas en tu nueva funcionalidad en la nueva branch, irás haciendo commit’s de tus cambios. Cuando tu desarrollo esté finalizado, es hora de hacer un pull request. En este momento, tu i tu equipo deberíais verificar y discutir los cambios del proyecto. Una vez consensuados los cambios con el resto del equipo, podrás hacer un merge en la branch:master. Veamos un ejemplo:
Creando una Branch
Abre tu repository y haz clic en la pestaña “Code”
- Haz clic en “Branch:master” del menú desplegable
- Indica el nombre para tu nueva branch (por ejemplo, ‘development’)
- Haz clic en “Create branch”
Ahora que ya tienes una nueva branch, puede modificar tu proyecto sin alterar el contenido de la branch:master.
Es importante no confundir una nueva branch con un fork, este último sirve para clonar otro repositorio a tu cuenta, permitiéndote iniciar un nuevo proyecto basado en un otro previo.
Commit de un archivo
Ahora puedes trabajar de forma segura dentro de nuestra nueva branch:development. Vamos a crear, o modificar, un nuevo archivo y lo subiremos con un commit.
- Edita un documento
- Aplica los cambios añadiendo un asunto y una descripción
- Asegúrate de que estás en la branch correcta branch:development
- Haz clic en “Commit changes”
¡Fantástico! Commit aplicado. Veamos como compartir los cambios con el equipo mediante un pull request.
Pull request
Una pull request es una funcionalidad básica para compartir tus cambios en el proyecto con el resto del equipo. Tu y tu equipo cada vez que hagáis un pull request deberíais analizar y revisar el código que han cambiado el resto de compañeros antes de aplicar los cambios a la branch:master.
- Abre la pestaña “Pull requests” y haz clic en “New pull request”
- En el primer menú desplegable: asegúrate de seleccionar la branch:master
- En el segundo menú desplegable: selecciona la branch:development que generaste anteriormente
- Haz clic en “Create pull requests”
- Indica un asunto y descripción de la pull y asegúrate que la información sea precisa exponiendo los cambios que se han realizado
- Haz clic en “Create pull request”
Tu equipo ahora tienen la capacidad de verificar y discutir los cambios propuestos. Una vez consensuados los cambios con tu equipo, podrás hacer un merge en la master branch.
Merging un Pull Request
- Dentro de la solicitud del “Pull request”, haz clic en “Merge pull request”
- Seguro? ;) Haz clic en “Confirm merge”
- Una vez que la branch se ha fusionado “merged”, es probable que ya no la necesites. Puedes eliminarla haciendo clic en “Delete branch”.
¡Genial! Ya tienes la branch:development fusionada “merged” en la branch:master, para que tus usuarios puedan disfrutar de la nueva funcionalidad.
Conclusión
Git es una herramienta indispensable en el desarrollo de tus proyectos y el trabajo en equipo. Ahora podrás crear nuevos repositories, issues y branches, enviando tus commits y solicitando los pull request para acabar aplicando un merge después revisar el código para unificar tu trabajo y el de tu equipo en la branch:master de tu proyecto.
¿Utilizas git en tus proyectos? ¿Cual es tu Workflow?
Fotografía: Pixabay
Fuentes: