Ya hemos visto cómo crear un repositorio con Git y ahora quiero hablar un poco acerca de las ramas en Git y su utilidad. Nuestro proyecto sólo es la estructura de archivos y no tenemos nada de código aún, ¿cómo continuar con el desarrollo? Lo ideal es que siempre trabajemos la versión estable de nuestros proyectos en la rama master que es el estándar bajo el ecosistema Gitero. Es posible usar otro nombre; pero como un amigo mío dijo:
Las convenciones existen por algo, si no las sigues es síntoma de que un proyecto OpenSource fracase.
La rama que vamos a crear y utilizar intensivamente en el desarrollo es conocida como develop. A partir de ella podemos desprender otras para desarrollar diferentes características de nuestro software sin afectar el desarrollo principal; ni mucho menos la versión estable del repositorio. Para mostrar las ramas existentes localmente ejecutamos: [php] $ git branch * master [/php] Entonces creamos la rama develop: [php] $ git branch develop $ git branch develop * master [/php] El asterisco al inicio del nombre de una rama nos indica que estamos en dicha rama. Para cambiar entre ramas debemos usar checkout: [php] $ git checkout develop Switched to branch ‘develop’ [/php] Bien, ahora ya estamos listos para comenzar el desarrollo de nuestro proyecto desde la rama develop. ¿No te parece genial?
Aprende: Qué es branch o rama en Git y sobre Git Merge
Es recomendable crear ramas **cuando los cambios que llevemos a cabo tenga una relación entre sí. **Por ejemplo, si vamos a editar sólo nuestros archivos en include/, sería conveniente crear una rama exclusivamente para los cambios realizados ahí. No es obligatorio, pero más adelante descubrirás el poder que te da separar nuestros cambios sin la posibilidad de afectar a otros archivos. Entonces, vamos a crear una rama llamada include-specs a partir de nuestra rama actual (develop) donde describiremos lo que hará nuestro software: [php] $ git checkout -b include-specs Switched to a new branch ‘include-specs’ [/php] Este sería el contenido de nuestro archivo include/funciones.php: [php] ‘valor’)); # asignación múltiple (fancy) config(function ($t) { $t->clave = ‘valor’; }); [/php] La bandera -b de checkout nos permite crear una nueva rama basada en la actual y cambiar a ella. Usualmente es un atajo que nos ahorra el trabajo de hacer lo siguiente: [php] $ git branch include-specs $ git checkout include-specs Switched to a new branch ‘include-specs’ [/php] Revisamos los cambios con status: [php] $ git status # On branch include-specs # Changes not staged for commit: # (use “git add <file>…” to update what will be committed) # (use “git checkout – <file>…” to discard changes in working directory) # # modified: include/funciones.php # no changes added to commit (use “git add” and/or “git commit -a”) [/php] Hacemos commit y revisamos cambios de nuevo: [php] $ git commit -am “Especificaciones para config()” 1 files changed, 13 insertions(+), 0 deletions(-) $ git status # On branch include-specs nothing to commit (working directory clean) [/php]
Descubre más sobre Git Merge
Ahora ya sabemos crear ramas y realizar cambios que sólo permanezcan ahí. Para comprobarlo, cambiamos a la rama develop y revisamos el contenido del archivo que modificamos en include-specs: [php] $ git checkout develop $ cat include/funciones.php [/php] No hay nada, y eso es bueno. Quiere decir que vamos bien. Ahora necesitamos comenzar a implementar la función config() para después hacer pruebas. Y si todo funciona como esperamos, combinamos el resultado a nuestra rama develop. En el siguiente paso, cambiamos de nuevo a la rama include-specs y agregamos lo siguiente a nuestro script de funciones: [php] /* Contenedor estático de configuraciones / function config($key = NULL, $val = NULL) { static $bag = array(); if (func_num_args() === 0) { // Si no hay argumentos devolvemos la configuración return $bag; } elseif (is_string($key)) { if (func_num_args() === 1) { // Si solo hay un argumento devolvemos la opción (getter) return isset($bag[$key]) ? $bag[$key] : NULL; } else { // Si hay dos argumentos asignamos un único valor (setter) $bag[$key] = $val; } } // TODO: implementar los specs restantes } / Pruebas */ print_r(config()); [/php] Verificamos la sintaxis y ejecutamos el script desde la consola: [php] $ php -l include/funciones.php No syntax errors detected in include/funciones.php $ php include/funciones.php Array ( [clave] => valor ) [/php] El script funciona, no en su totalidad, pero cumple al menos una de las especificaciones que contemplamos en nuestro script inicialmente. Si no queremos perder los cambios que llevamos hasta este punto vamos a hacer commit y no más. [php] $ git commit -am “El primer spec funciona, y muy bien” 1 files changed, 27 insertions(+), 0 deletions(-) [/php] Las banderas -am nos permiten agregar automáticamente los archivos modificados y establecer un mensaje para el commit.
Hemos creado ya la rama develop, una auxiliar include-specs para separar los cambios en porciones y ya verificamos que nuestro código cumple las expectativas que nos planteamos. Entonces ya es tiempo de formalizar todo esto y llevar los cambios hacia la rama de desarrollo. Para lograrlo debemos utilizar merge y finalizar nuestro trabajo del día de hoy: [php] $ git checkout develop Switched to branch ‘develop’ $ git merge include-specs Updating 14d8578…cfdd6ae Fast-forward include/funciones.php | 40 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+), 0 deletions(-) [/php] Y ahí tenemos, integramos nuestros cambios realizados en la rama auxiliar a la rama oficial de desarrollo. Integrar cambios es lo más sencillo del mundo si mantenemos la calma y trabajamos en orden, despacio y por partes. Si nos ponemos a editar y mover mucho código en una sola sesión de commits, lo más probable es que encontremos conflictos cuando intentemos mezclar los cambios. Es importante notar que no trabajamos directamente sobre la rama develop, y mucho menos con la rama master. Y, por esta razón es conveniente hacer todo en un solo sitio. Las ramas están diseñadas para esto y ahora ya sabes que, efectivamente, funcionan. Esto te ayudará a no poner en riesgo la integridad y estabilidad de tu software. Aunque no hemos terminado de usar la rama include-specs, vamos a suponer que ya no sirve. Esto porque nuestro código se encuentra estable y necesitamos eliminar referencias innecesarias. Veamos lo siguiente para ejemplificar: [php] $ git branch experimental $ git branch -d experimental Deleted branch experimental (was cfdd6ae). [/php] Por ahora no vamos a profundizar a detalle sobre banderas y opciones de cada comando así como ningún tipo de técnica avanzada. La idea de estos ejercicios es mostrar el flujo de trabajo más sencillo posible que se puede llevar a cabo con Git. Hay escenarios mas complejos y cuando se trabaja con más de una persona pueden suceder cosas complicadas, pero no hay que temer, Git es el salvador de nuestro código. Consulta el repositorio de este ejemplo en Git. Y si quieres aprender cómo mejorar tu flujo de trabajo y mantener el control de versiones de código de tus proyectos, regístrate hoy al curso de Git y GitHub en Platzi. Aprenderás todo lo que necesitas saber, desde cero.
