5 Comandos GIT Que Deberías Conocer

5 comandos GIT que deberías conocer

Que pasa chumachos!

Si estas leyendo esto en 2016 y no sabes que es GIT vas apañao. ¿Si te digo Sistema de Control de Versiones (CVS) te suena mas? ¿Si? ¿No? ¿No sabes no contestas? Bueno… en fin… vamos con una primera definición de la Wikipedia…

Git (pronunciado “guit”) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente

Ufff…. esto tampoco lo deja muy claro, bueno intentaré realizar una explicación mas simple mediante ejemplos, ¿cómo si no?…

Imagina que estas trabajando en un proyecto junto a un compañero, escribes un pedazo de código, lo pruebas en desarrollo y lo subes a pre-producción. A la semana, tu compañero encuentra un bug en ese pedazo de código tuyo, lo encuentra y lo arregla pero no quiere borrar tu código porque cree que mas adelante puede refactorizarlo para hacer un código mas limpio así que lo comenta en bloque para que, aunque no sea funcional, poder revisarlo mas adelante.

Siguen pasando las semanas de desarrollo y las subidas semanales a pre y producción y obviamente tu compañero y tu seguís con esta practica de comentar código, llegará un momento en que no sabréis que versión del código tenéis cada uno y que versión de código esta desplegado en producción. Se trasca la magedia…

Pues esta realidad tan arcaica fue algo muy común en los desarrollos hasta que llegaron los Sistemas de Control de Versiones y aunque en un primer impacto está pensado para el código fuente y ficheros en texto plano no es algo determinante ya que puedes aplicarlo a cualquier tipo de fichero informático, aunque luego tengas que leer trazas en base64 al resolver conflictos xD

Así pues con GIT vas a poder mantener tantas versiones como quieras de un fichero pudiendo volver atrás en el tiempo para rescatar un cambio que hiciste incluso, y aquí viene lo chulo, podéis trabajar varias personas sobre el mismo fichero sin tener miedo a perder cambios o pisaros los unos a los otros.

Actualmente el BFS (Big Fucking System) de este tipo de software es GIT, es el rey de todos los sistemas de control de versiones y mas junto a la plataforma Github que sirve para alojar proyectos Open Source utilizando este sistema aunque por supuesto existen otros competidores en el juego como Subversion o SourceSafe aunque están a años luz del rey.

Así pues, una vez hechas las presentaciones vamos a ver los comandos git típicos que deberías conocer para desenvolverte con total fluidez a la hora de versionar tu trabajo y sobre todo qué es lo que puedes hacer con GIT.

 

Los comandos git de los campeones

Has escrito código nuevo y lo quieres guardar en el servidor para que el resto de los compañeros puedan descargar tu aportación, con la siguiente secuencia de comandos git lo puedes hacer muy facilmente.

git add fichero.php imagen.png script.sql
git commit -m 'Adding my first changes'
git push origin issue/rama

Con estos comandos lo que estas haciendo es añadir tres ficheros (fichero.php, imagen.png y script.sql) al área de preparación y le añades un comentario específico a ese commit, para que trackearlo y después puedas encontrarlo rápidamente si es que lo necesitas. Con el último comando, push, estas enviando tus cambios a la rama issue/rama que se encuentra en el servidor origin, nombre por defecto que le da GIT al servidor.

Estos comandos git te permiten enviar cambios al repositorio

Estos comandos git te permiten enviar cambios al repositorio

 

¿Fácil no? ¿Pero y si lo que queremos es descargarnos los cambios de un compañero que están alojados en otra rama del servidor? Pues con los siguientes comandos git podemos hacerlo…

git checkout issue/rama_de_tu_compi
git pull origin issue/rama_de_tu_compi

El primer comando te cambiará tu área de trabajo a la rama issue/rama_de_tu_compi y con el segundo traerá los cambios que no hayas descargado de esa misma rama.

Guay, el utilizar estos dos comandos a la perfección son la esencia de GIT ya que sino no vas a poder trabajar, vamos mas básico que esto no hay nada. Hacer cambios y confirmarlos y descargarse cambios. Fin.

Pero vamos a ver otros comandos git un poco mas complicados o de Pro Master, coño.

Imagínate que estas felizmente trabajando en tu rama issue/rama y has tocado varios ficheros pero justo ha entrado una incidencia crítica que tienes que resolver que exige que cambies de rama pero no quieres perder esos ficheros modificados, aunque tampoco quieres mandarlos al servidor porque aun no están preparados. Bueno pues GIT tiene unos comandos para guardar de manera temporal estos cambios y luego poder recuperarlos.

git stash
git stash list
git stash apply

El primer comando va a guardar esos cambios no confirmados de manera provisional en tu máquina local. Importante resaltarlo ya que no se envían al repostorio. Con el segundo comando verás un listado de los diferentes conjuntos de ficheros almacenados provisionalmente y correctamente etiquetados con un hash. El último comando es para volver a aplicar sobre la rama los cambios que habías guardado de forma temporal en tu ordenador.

Si ejecutas el stash apply como pone en el ejemplo, se aplicarán los cambios de todos los ficheros, si quieres solo aplicar algún cambio en concreto habrá que pasarle al comando el hash identificativo que antes veíamos con el stash list.

¿Hasta aquí bien verdad?

Ok, pues imagina que estas trabajando en el fichero fichero.php y en el momento de commitearlo la cagas y ejecutas un git add *, esto lo que hace es enviar todos los ficheros al área de preparación. Obviamente solo quieres enviar fichero.php y también se te ha añadido script.sql porque detecta un cambio que no quieres enviar. Okay, que no cunda el pánico.

Para sacar un fichero del área de preparación y deshacer los cambios ejecuta los siguientes comandos git.

git reset HEAD script.php
git checkout -- script.php

Ale, ya esta fuera del área y lo has dejado como si no lo hubieses modificado, ya puedes ir a por el commit 😉

jeje pero que exagerado, si hay un incendio primero hay que hacer un git add *

jeje pero que exagerado, si hay un incendio primero hay que hacer un git add *

 

Muy bien si ya has conseguido llegar hasta el punto de modificar algo y enviarlo al servidor, eso teóricamente significa que tus cambios están listos para ser incluidos en la rama master.

La rama master es la rama que mantiene el código o los cambios que van a producción, aquí se encuentra la versión oficial y definitiva de los cambios, con la rama master no se juega.

Así que si tus cambios ya están terminados y han sido aprobados acabarán aquí. Muy bien, haces el commit y el push y en el momento de solicitar un pull request para que incluyan tus cambios sobre master… Meeeck, error, aparecen conflictos y no se puede mezclar. Aaaahhh la puta, a todos nos ha pasado y da muchísimo por culo.

La principal causa de que no puedas mergear tus cambios sobre la rama master es que en el momento de realizar los cambios en tu máquina no estabas completamente actualizado y sincronizado con el código de master o lo estuviste en el momento de abrir la rama para comenzar a trabajar pero algún listo ha hecho cambios que tu no tienes por lo que te has quedado completamente desfasado. Anda que no jode…

Bueno pues es tan sencillo como ejecutar los siguientes comandos git.

git checkout master
git pull
git checkout issue/rama
git merge master
git commit -m 'Merging master branch into issue/rama to avoid conflicts'
git push origin issue/rama

Con esto lo que estas haciendo es volverte a bajar master y actualizarla para que una vez tienes todo el código sincronizado con el repositorio actualizar tu rama issue/rama mezclando el código de master con ella misma. Creo que se entiende bien ¿no? Los otros comandos git ya los hemos visto mas arriba…

Como todo, y a raíz de esto, unos te dirán que todas las ramas deben de salir desde la rama development y que únicamente saldrán desde master cuando se trate de un hotfix y otros empezarán todas sus ramas desde master… en fin, toda esta filosofía git depende de como este organizado el proyecto ya que la teoría de ramas da para mucho, muchísimo, para un artículo enterito casi casi xD

En fin, esto es lo bueno de trabajar con GIT, ofrece flexibilidad ilimitada para que cualquier equipo de trabajo pueda organizar y mantener su propio proyecto como le de la gana, aunque también te digo que hay unas recomendaciones y buenas prácticas que ya veremos en otro momento…

Pues nada chachos, hasta aquí mi artículo sobre comandos GIT y segundo listado del 2016, Gorka eres un bocazas si tenéis alguna duda sabéis que podéis dejarla en los comentarios o utilizar twitter a través del siguiente banner 😉

@gorkakatua #faqsGorkamu pregúntame por twitter cualquier cosa y vemos cómo lo solucionamos.

 

Hala a chuparla!

¿Te ha parecido este un artículo de 5 estrellas? Dame tu valoración:
Review Date
Reviewed Item
5 comandos GIT que deberías conocer
Author Rating
5

Gorka Muñoz Andrés

Me llamo Gorka Muñoz y soy un desarrollador melómano. Combino a la perfección la búsqueda de nuevos grupos con la pasión por la tecnología. Desde chiquitito me ha gustado la programación, ahora que soy mayor estoy metido en el mundo del SEO sin olvidarme del /Dev.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *