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](https://binary-coffee.dev/post/hablemos-un-poco-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](https://git-scm.com/book/en/v2/images/lifecycle.png) - **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](https://github.com) o [gitlab](http://gitlab.com). 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 - [git-scm.com](https://git-scm.com/) ## 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](https://youtube.com) 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