BACK TO BASICS: GIT
PEQUEÑO CURSO DE GIT
Este pequeño repaso a algunos comandos comunes nos van a dar una pincelada para conocer el funcionamiento de Git y sus múltiples opciones.
A pesar de ser una herramienta que puede ser muy compleja, con conocer una serie de comandos que nos ayuden a movernos a través de nuestros proyectos, será suficiente para poder tener un mínimo control sobre el proyecto y sus ramas.
No es ni de lejos una guía exhaustiva, sino una pequeña guía para emprender unos primeros pasos y poder movernos por Git con seguridad.
1. Git config –global: esto hará que cualquier uso en el equipo utilice esta configuración
user.name «nombre»
user.email «email»
Podemos hacer scripts con git config –global alias.nombre «comando»
Sin la configuración de nombre y correo, Git no puede funcionar. Sin una referencia a la persona que hace los cambios que se generan durante el proyecto, iríamos a ciegas.
2.1 git init : sencillamente, para empezar a trabajar con git en un directorio tenemos que incializar git. Una vez tengamos inicializado git nos veremos con un resultado similar a este:
Podemos modificar el nombre de la rama principal antes del inicio con
git config –global init.defaultBranch nombre_de_rama_maestra
o utilizar el comando git branch -m < nombre_de_rama_maestra >.
Por defecto, Git en su CLI nos dará la rama Master como principal.
2.2 git clone: en vez de incializar un proyecto, podemos ¡ntroducir en nuestra carpeta una dirección Http o ssh con el repositorio que queremos clonar, y dentro de ella aparecerá el proyecto clonado.
Ej: https://github.com/jortilles/miProyecto.git
Ej: git@github.com/jortilles/miProyecto.git
3. git status: lo usaremos para conocer el estado de los archivos de la carpeta que estan pendientes de tracking, pendientes de commit o similares estados.
4. git add: lo usaremos para añdir los archivos a estado de stage.
git add < nombre_del_archivo >
Podemos usar git add . para añadir todos los archivos listados o modificados pendientes de stage que se encuentran en el directorio.
5. git commit: todos los archivos que están en stage los pasaremos al proyecto.
Todo commit tiene asociado un mensaje de cabecera y se le puede añadir descripción.
Podemos usar «git commit -m «mensaje» para saltarnos la pantalla que pide introducir un mensaje. Recomendamos este uso.
6. git log: tracker de todo el trabajo de esta carpeta git.
Hay opciones para hacerlo bonito con git log –graph
En el punto 11 veremos git reflog, donde sale TODO el movimiento que hemos generado en el proyecto.
En el gráfico vemos como usando el comando –graph, nos genera a la izquierda una línea roja , que es la rama master. El primer commit en la lista siempre será el último que hemos desarrollado. En este caso, además, muestra como en local de nuestra rama master, estamos en la posición HEAD, que la rama remota origin/master también está situada en el mismo lugar y que este remoto también está en la misma posición.
7. git checkout:esta es una de las herramientas más importantes y poderosas de Git
Por ejemplo, nos puede situar en un punto concreto del flujo o podemos cambiar de rama, ir a un hash concreto, etc…
Pongamos un ejempo.
Queremos volver al punto exactamente anterior al que estamos pues el cambio no convence del todo. Vamos allá!
Atención! Recomendamos hacer una captura o copia de los hashes en un documento de texto para poder tener a mano los datos necesarios
– Volvemos a un commit anterior usando git checkout <numero de hash>, veremos como estamos en un punto anterior del flujo despegados del HEAD, que es el punto donde nos encontrabamos en la actualidad. Podemos volver al punto que deseamos usando el hash correspondiente. Veremos también como en vez de la rama en la que estamos, aparece otra numeración.
Vemos como nos avisa: estamos en estado de “detached HEAD”. Como podemos comprobar, podemos tocar, hacer una rama nueva, etc…
También vemos como de repente, ya no estamos en la rama “master” sino que se nos otorga el hash del commit.
– Si hacemos git checkout HEADcuando estamos situandosen este commit anterior, este se convertirá en el HEAD del proyecto (pero tranquilos, a pesar de lo que parece, no hemos perdido el trabajo posterior)
– Si volvemos a señalar un git checkout a nuestro punto original, será el HEAD directamente
– Si hacemos git checkout <nombre_de_rama>, veremos que la rama detached desaparece y que estamos de nuevo en el HEAD donde estuvimos antes de movernos.
En la captura, podeis ver como pasamos de un commit anterior (e7…) al último que hemos usado (f8…) y de vuelta a master.
Os animamos a probar las múltiples opciones de git checkout, ya que es un recurso un poco difícil de entender sin práctica. Una vez tomado el pulso, es muy efectivo!
8. git reset: en un punto concreto del flujo, se puede usar para volver al punto guardado en el que estamos del hash si no le hemos commiteado.
Si usamos git reset –h <hash_del_commit>, iremos directamente al commit inidicado y nos posiciona en HEAD. Esta opción es interesante si queremos volver atrás, pero debemos recordar que el trabajo posterior será “eliminado” (eliminado es entre comillas, pues podremos encontrarlo en un futuro gracias a git reflog)
9. archivo .gitignore: este archivo es una suerte de salvavidas ante situaciones no deseadas.
Siempre tendremos algunos archivos que no queremos que se suban a remoto o se modifiquen, pues pueden ser archivos de prueba, de configuración local, que puedan contener información sensible como contraseñas o cualquier otra posibilidad. Asi que sencillamente, si creamos un archivo llamado .gitignore, en su interior podemos introducir con este formato los archivos o carpetas de lo que no queremos subir a remoto:
**/<nombredelarchivo o carpeta>
Tendremos que añadir siempre el archivo .gitignore al flujo, y si hay que añadirle datos, comitearlos y empujarlos a remoto.
10. git diff: nos muestra las diferencias que hay entre el punto actual y las modificaciones que tenemos hechas en los archivos locales.
También lo podemos usar para comparar ramas añadiendo la rama a comparar
git diff <rama_a_comparar>
11. git reflog: nos dará un historial completo de nuestro movimientos, sea un cambio de rama, un commit, un checkout, etc….
Podremos así reusar hashes que desviamos o dejamos atrás gracias a esto.
Este comando es enormemente interesante, pues a veces tendremos la sensación de perder la situación. Con esta opción, nos saldrá absolutamente todo el historial del proyecto, pudiendo recuperar commits que dimos por perdidos y utilizar la posición con un git checkout.
12. git tag “etiqueta”: podemos etiquetar hitos importantes en el proyecto creando etiquetas para señalar hechos importantes. De esta forma, si queremos recuperar el commit donde está la etiqueta, podemos hacer un git checkout “etiqueta”.
Ojo, nos pondrá la etiqueta en la posición HEAD.
à Es muy importante entender bien el concepto del trabajo en ramas. Os recomendamos visitar esta web que lo explica genial: https://www.atlassian.com/es/git/tutorials/using-branches#:~:text=En%20Git%2C%20las%20ramas%20son,rama%20para%20alojar%20estos%20cambios
13.0 git branch: nos dará los nombres de ramas disponibles en el proyecto y resaltará en color la rama sobre la que nos encontramos en el momento de la solicitud.
13.1. git branch <nombre_de_rama >: añadirá una rama nueva en la posición del HEAD.
14. git switch <nombre_de_rama >: cambiaremos hacia la rama que escojamos para trabajar
Es importante fijarnos que, con el IDE o editor gráfico de código que estemos usando, si modificamos la rama en git bash, se hará también en el IDE.
15. git merge: combinamos y añadimos los datos de una rama externa sobre la que estamos trabajando.
Ej: Si estamos trabajando en master y queremos traer el trabajo de otra rama haremos
git merge <rama>
De esta forma traeremos el trabajo que hemos hecho en la rama externa hacia la rama master.
Pero Sorpresa! No has podido hacer merge correctamente! Ha usrgido un… CONFLICTO.
****** CONFLICTOS: es común cuando intentamos hacer merge que haya cambios entre las mismas líneas de las diferentes ramas, remotas y/o locales, y que se tenga que escoger cual es la correcta.
En Vscode aparece en colores el conflicto una vez emerge, y podemos escoger cual es nuestro interés. Una vez elegido la corrección, tenemos que pasar a stage los archivos en la resolución del conflicto; de nuevo hacer git add «archivo» y commit.
Parece sencillo, pero a veces estos cambios son complejos. Recomendamos siempre, antes de confirmar cambios, asegurar el resultado revisando el documento una y otra vez, entendiendo los cambios locales y los que entran de remoto para resolver correctamente y no perder información.
En los
16. git stash: se puede usar para guardar un proceso inacabado y así poder cambiar de rama y no perder el trabajo no commiteado. Git no nos dejará cambiar de rama o hacer checkout si hay algún cambio no registrado, asi que podemos hacer stash para que no se pierda la info.
De esta forma, git stash permite guardar sin commitear un proceso sin finalizar.
Con git stash list veremos la lista de stashes en la rama que hay abiertos.
Si hacemos git stash pop, reemergerá los cambios sin finalizar
Si hacemos git stash drop, eliminaremos los borradores guardados.
17. git branch -d <rama>: lo usaremos para eliminar la rama con la que ya hemos acabado de trabajar y que su trabajo está implementada en master.
Estos son tan solo algunas opciones interesantes que nos ofrece Git, una de las herramientas más usadas en el mundo del desarrollo y la programación.
Destacar que podemos usar todo tipo de archivos, no solo archivos de texto, sino también archivos de imagen, pdf´s, etc….
Hay tantas maneras de usar Git como personas que lo usan. Os animamos a hacer vuestros propios protocolos de trabajo con Git y a manipularlo tanto a través del CLI (más conocido como Git Bash) o a través de las diferentes GUI que hay disponibles.
El GUI favorito de Jortilles es Fork: https://git-fork.com/ Es muy efectivo en su visualización para ver la situación y posición en todo momento del proyecto, y forma de trabajar es casi intuitiva. También, en caso de conflictos y errores, suele ayudar mucho con sus pantallas partidas, avisos y tips.
