Binary Coffee

Operaciones b√°sicas con GIT

git github gitlab

Luego de varios a√Īos trabajando con Git, he notado que muchos desarrolladores en cierto modo temen a hacer ciertas operaciones como merge y rebase sobre el grafo de cambios. Del mismo modo se hace a ver mucho el desconocimiento de conceptos tan simples como las diferencias entre ramas locales y ramas remotas y el c√≥mo trabajar con las mismas. Personalmente creo, que esto se debe al uso de herramientas intermedias como GitKraken, que creo evitan al desarrollador el empaparse con las operaciones b√°sicas en Git y le hacen dependientes de los mismo. Por esto, en el art√≠culo tratar√© aspectos que he identificado como los de mayor importancia y que usualmente los desarrolladores no utilizan o desconocen.

Antes de empezar, les recomendamos echarle un ojo al artículo sobre Control de Versiones y Git.

Sumario

  1. Ciclo de vida del estado de los archivos
  2. Guardando cambios sin hacer commit (stash)
  3. Manipulación de ramas

1. Ciclo de vida del estado de los archivos

Se hace necesario antes de empezar a trabajar con Git, conocer a fondo cuales son los estados por los que transitan los cambios en Git y el cómo utilizarlos. A continuación se muestra un diagrama donde se puedes ver los 4 estados en los que un archivo puede estar en Git.

estados

  • Untracked: mientras el archivo no a sido incluido en el control de versiones
  • Unmodified: el archivo ya est√° bajo el control de versiones y no ha sufrido cambios
  • Modified: archivo bajo el control de versiones con cambios
  • Staged: archivo bajo el control de versiones con cambios y que hemos marcado para el commit

Tomando como base la imagen anterior, vayamos viéndolo con un ejemplo práctico. Primeramente creamos un archivo en nuestro proyecto, esto significa que estará en el estado Untracked, por tanto sólo puede prepararse para ser puesto en un commit. Para poner dicho archivo en el estado de Staged se utiliza el comando add.

$ git add new-file.txt

Esto significa que el nuevo archivo est√° listo para ser puesto en un commit.

$ git commit -m "Create new file"

Una vez hecho esto el archivo fue puesto bajo el control de versiones y por tanto pasa al estado Unmodified, pero si le agregamos una nueva línea implicaría que dicho archivo pasaría al estado Modified. Como en el ejemplo anterior con el comando add lo podemos pasar al estado Staged y luego hacer commit del mismo

$ git add new-file.txt
$ git commit -m "Add new line into new file"

Un dato importante a tener en cuenta, es cómo saber que archivos tenemos en Staged, Untracked y Modified y esto puede ser comprobado con el comando status. A continuación un ejemplo de la salida del comando

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   new-file.txt

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:   new-file2.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    new-file3.txt

Otra acci√≥n importante a tener en cuenta, es c√≥mo devolver archivos del estado Staged a Modified/Untracked. Esto es sencillo con el uso del comando reset que b√°sicamente elimina todo lo que tenemos en Staged y lo pone nuevamente en Modified o en Untracked seg√ļn el origen de dicho archivo.

NOTA: El comando git reset no elimina cambios, solo modifica el estado de los cambios.

Guardando cambios sin hacer commit (stash)

Otra herramienta interesante con que cuenta Git, es el stash. B√°sicamente lo que se puede hacer con el stash, es que cuando contamos con cambios (archivos en el estado Modified) y deseamos guardar estos cambios pero sin hacer un commit, podemos hacerlo con un stash.

Las razones por las que nos puede hacer falta hacer stash son varias, pero por la que m√°s lo utilizo, es cuando necesito bajar los √ļltimos cambios de la rama en que me encuentro trabajando y tengo archivos modificados. en este caso, Git te proh√≠be de hacer el pull con un mensaje que indica que tienes archivos modificados. Entonces aqu√≠ es donde utilizo el stash, de la siguiente manera:

git stash

esto automáticamente crea una salva de los cambios que tenemos (archivos en Modified) y genera un stash. Para revisar los stash que tenemos actualmente, puedes ejecutar el siguiente comando git stash list, que listará los stash con que se cuenta. Y luego de hacerse el git pull (el ejemplo que mencioné anteriormente), pues vuelvo a aplicar los cambios almacenados en el stash. Esto se logra con el siguiente comando

git stash pop

Este comando elimina el √ļltimo stash que realizamos y lo aplica en el proyecto. Esta herramienta es muy √ļtil y desde mi experiencia, es muy poco utilizada e incluso conocida por muchos desarrolladores.

Utilizando las ramas en Git

Definitivamente una de las cosas que debemos dominar a la hora de trabajar con Git es la manipulación de las ramas del proyecto. Cuando decimos manipular ramas, nos referimos a la creación y eliminación. Pero además, también hablaremos un poco de los tipos de ramas y las diferencias entre ellas.

En este punto quiero mencionar como lo m√°s importante, el concepto de rama local y rama remota. Esto es debido a que es uno de los aspectos en que mayor desconocimiento he visto.

rama local: es toda aquella rama que creamos en nuestro proyecto local y nos permite llevar cambios y modificación de manera local.

rama remota: es aquella rama que se encuentra en los repositorios remotos, dígase github o gitlab. Estas ramas usualmente son atadas a una rama local y de esa manera vamos llevando los cambios entre la remota y la local.

A continuación mostraremos cómo crear ramas (locales y remotas) y también cómo enlazar una rama remota a una local.

Primeramente, cómo crear una rama nueva. Esto se puede hacer con el siguiente comando:

$ git branch new

Con el comando anterior, creamos una rama nueva con el nombre new. Si se desea ver las ramas existentes, lo puedes hacer con el comando:

$ git branch
* master
  new

La rama que tiene el asterisco al inicio, es aquella en la que nos encontramos trabajando. Lo siguiente que deberíamos poder hacer, es cambiar de rama, y para esto utilizamos el siguiente comando.

$ git checkout new

De momento todo lo que realizamos fueron acciones en ramas locales, a continuación empezaremos a ver un poco sobre ramas remotas. Para crear una rama remota primeramente crearemos un proyecto en Github (puede ser Gitlab también) y creamos el remote en el proyecto local para enlazar el proyecto con dicho repositorio. Una vez creado el repositorio, asumiendo que la dirección en Github es https://github.com/dcs-community/new-repo, ejecutamos el siguiente comando para crear el remote en el proyecto local:

$ git remote add origin https://github.com/dcs-community/new-repo

Una vez hecho esto ya podemos crear una rama remota. Decir en este punto, que se puede tanto crear una rama remota, como crear la versión remota de una de las ramas locales que tenemos creadas. Empecemos por crear una versión remota de la rama que tenemos seleccionada en este momento (la rama new que creamos anteriormente):

$ git push -u origin new

Con el comando anterior creamos una rama remota que está enlazada a nuestra rama local. El parámetro -u significa set upstream, esto es para crear el enlace entre la rama local y la rama remota. Si como en el ejemplo anterior se utiliza el mismo comando sin utilizar el parámetro -u, se creará una rama remota pero sin enlace a nuestra rama local, lo que significa que si hacemos pull, los cambios en la remota no se aplicarán en la local. Por otro lado si deseamos crear una rama remota que no esté atada a la rama actual ni tenga el mismo nombre, podemos ejecutar el siguiente comando:

$ git push origin HEAD:this-is-my-remote-branch

En el ejemplo anterior creamos una rama con el nombre this-is-my-remote-branch, y el parámetro HEAD para aquellos que no lo conozcan, es un apuntador simbólico que define donde nos encontramos. Por ello el comando se describe como crear una rama remota a partir de donde nos encontramos con un nombre definido (git push <remote> HEAD:<branch-name>)

Enlaces

Conclusiones

En este artículo quería tratar también otro tema interesante sobre Git, que es la manipulación del árbol de Git, pero se hicieron muy extensos los temas tratados, decidí llevar este contenido a un nuevo artículo. Además de esto, estamos pensando en crear algunos contenidos en video, explicando más a fondo todo lo que abordamos en el artículo, para que todos aquellos que tienen acceso a YouTube los puedan ver.

Esperamos los temas abordado fuesen de su agrado y que de alguna manera este conocimiento influya en cómo ves el Git ahora y que se pierda el miedo a la consola. Y ya saben, cualquier duda o sugerencia pueden dejarla en los comentarios.

Happy Coding!

Opiniones
noavatar
Hasta donde se, solo localmente. Si quieres hacer algo remoto, pues para ello tienes commits y ramas.
noavatar
stash funciona solo localmente o también remoto?