Oliver Servín

Desarrollador full-stack en Shipwork

Publicaciones Artículos

stash.

El Stash es un lugar en Git que tenemos para almacenar cambios temporales. Lo utilizamos con el comando git stash. El comando también acepta un mensaje con -m "<mensaje>". Podemos ver una lista de lo que hemos guardado en el stash con stash show.

Como podemos almacenar múltiples cambios en el stash, siempre es útil agregar un mensaje a un stash porque así podemos recordar de qué se trataba el cambio guardado y diferenciarlo de los otros.

Para recuperar un cambio guardado en el stash utilizamos el comando git stash index con el índice del stash que podemos ver con stash list.

rebase en repos privados.

Hacer un rebase en branches privadas siempre es mejor que hacer un merge, ya que esto hace que los commits de la branch queden por encima de la branch a la que se hace merge.

Muy útil cuando se quiere hacer un revert, mucho más fácil hacerlo sobre un solo commit que hacerlo sobre múltiples commits que además pueden incluir un merge conflict.

fetch vs pull.

git pull es como git fetch, pero al mismo tiempo realiza un merge con la branch actual.

git fetch con merge.

git fetch <remote> <branch> es el comando para obtener el historial de un repo remoto. Sin embargo, esto no actualiza nuestro repo actual con los cambios que haya en el repo remoto. Para eso es necesario tambien hacer un merge.

Convencionalismo para nombrar repos remotos.

Por convención, normalmente si nuestro repo es un fork, entonces cuando añadimos el repo remoto y lo nombramos como upstream en vez de origin.

Inicializando un repo remoto.

Para inicializar un repositorio remoto utilizamos el comando git remote add origin <repo-location>. La ubicación también puede ser un directorio local.

Remote local.

Para utilizar Git remote realmente no es necesario que sea un servicio como GitHub. También podemos utilizar una ubicación a un directorio en el mismo sistema.

Recuperar commit.

Para recuperar un commit realizado en una branch que ya hemos eliminado, podemos recuperar el commit utilizando git log para obtener el sha, después usar cat-file -p para acceder la branch y obtener el sha del archivo que queremos recuperar y ver su contenido.

Otra opción es simplemente utilizar merge con el sha de la branch que obtuviste antes. Sin embargo, es posible que el commit diverja y entonces tendríamos un merge conflict. Otra desventaja es que al hacer esto nos traemos todo el historial de la branch y quizá no sea lo que queremos.

Otra opción más es utilizar cherry-pick que lo que hace es tomar un solo commit específico con el sha y añadirlo por delante del historial de nuestra branch actual. Un requisito para usarlo es que requiere que tengamos un working tree limpio. Este comando es excesivamente útil y vital tenerlo a la mano.

reflog.

reflog es un comando que muestra un historial de todas las decisiones pasadas hechas, es decir, todas las acciones que se han realizado como los cambios de branch, los commits realizados, etcétera. Para limitar el número de líneas que se muestran podemos utilizar el flag ‑<number>.

merge vs rebase.

Una buena regla a seguir es utilizar merge en Git para branches públicas y rebase únicamente para branches privadas.

Ventajas de git rebase.

Al utilizar rebase en Git permite evitar merge conflicts.

Lo bueno del rebase es que ayuda a mantener un history limplio, sin embargo esto signigica alterar el history de una branch.

Por eso no es recomdable utilizar rebase en branches públicas.

git merge sin commit en común.

Al utilizar git merge <branch name>, lo que intentará es encontrar un commit común entre dos ramas. Si no lo encuentra, podría haber un merge conflict.

Git branch.

Para crear una branch se utiliza el comando git branch foo, lo cual crea una branch con el último commit de la branch actual.

Este comando crea la branch pero no realiza el cambio a la nueva branch. Para cambiar de branch podemos utilizar el comando git checkout <branch name>.

Otra forma de crear branches y cambiar de branch al mismo tiempo es utilizando el comando git checkout -b <branch name>.

Eliminar una config.

Para eliminar una configuración en Git, utilizamos el comando config unset.

Hay que tomar en cuenta que si hay valores repetidos, entonces no se podrán eliminar. Para eliminarlos, habrá que utilizar el comando con el argumento --unset-all.

Si queremos eliminar una sección por completo, utilizamos el argumento --remove-section.

Recordar que cada configuración está conformada por <section.key> value.

Presedencia de configuraciones.

En Git, los valores de configuración se pueden repetir y, cuando se obtiene el valor, el que toma precedencia es el último que se haya añadido.

Si una configuración está establecida tanto de manera global como local, la que toma precedencia es la local.

Inspeccionar commit.

Es posible inspeccionar un commit con el comando git cat-file -p <sha>. Con este comando le pasamos el SHA de un commit realizado.

Esto nos mostrará el sha del tree pero también el del parent. Si inspeccionamos de nuevo el sha del tree, mostrará los archivos dentro del commit. Y si inspeccionamos por último el sha del archivo, entonces podremos ver el contenido del archivo.

Con esto confirmamos que Git no almacena diferencias, sino que cada sha contiene el sha parent, que es un marcador para ir escalando en el tree e ir completando nuestro proyecto.

SHA.

Cada commit que hagamos se le asigna un SHA, el cual es generado basándose en el email, el nombre que hayamos configurado, además de la fecha, la hora y los archivos commiteados.

Hitorial Git.

Si queremos ver el historial de nuestro repo, podemos utilizar el comando git log.

Primer commit.

Para crear un primer commit, primero creamos un archivo archivo.md, revisamos el estado con git status, que nos indicará que tenemos un archivo untracked.

Después utilizamos el comando git add archivo.md para añadir el archivo al área de staging, revisamos el estado con git status y confirmamos que el archivo está en staging.

Ahora realizamos el commit con el comando git commit -m "mi primer commit", volvemos a revisar el estado de git con git status y nos confirmará que nuestro working area está limpia, es decir, que no hay archivos untracked o con cambios.

Comandos más usados.

Básicamente, el 80% del tiempo que interactuamos con Git estaremos utilizando los siguientes comandos:

  • git add
  • git commit
  • git status

Inicializar un repo.

Para crear un repo, se utiliza el comando git init, que inicializará un proyecto git. Esto creará una carpeta .git dentro de la carpeta de nuestro proyecto.

Comandos de configuración.

Los comandos para utilizar git config son: uno, para establecer una configuración en Git se utiliza el comando git config --add --global <key>.<value>; dos, para ver la configuración de un elemento de git se utiliza el comando: git config --get key.

Config indispensable.

Los valores de las configuraciones de user.name y user.email son los que se utilizan y se almacenan dentro de cada commit.

Esquema de configuraciones en Git.

Todas las configuraciones de git tienen la forma de <section>.<key> y el flag --global al utilizar el comando git config hará que sea una configuración global para todos los proyectos.

Configuración de Git por proyecto y global.

Para configurar la experiencia con Git, podemos utilizar configuraciones locales o globales. Una configuración global se aplicará para todos los proyectos y una configuración local se aplicará únicamente para el proyecto actual.

Comandos Git más usados.

Los comandos que la mayoría de nosotros usamos se reducen básicamente a seis: push, pull, add, commit, status y fetch.

Manual de comandos Git.

Es posible utilizar el comando man git-<comando> para ver el manual de usuario y entender cómo funciona ese comando en específico.

Los comandos suelen estar bien documentados, lo que es de gran ayuda para entender o saber cómo funciona cierto comando.

Cuidado con eliminar archivos untracked.

Cuando hay archivos untracked en un proyecto y se eliminan, serán borrados por completo, porque Git no tiene un registro de esos archivos y no puede revisar el historial para restablecerlos.

Términos clave para entender Git.

Algunos términos clave para entender Git son:

  • repo, que básicamente es una carpeta .git dentro de otra carpeta que sería nuestro proyecto a trabajar.
  • commit, que es un punto específico en la línea del tiempo. Un commit representa completamente el proyecto. Realmente no almacena diferencias, sino todo el proyecto en un momento específico.
  • index y a veces staging, que es el área donde se prepararán los archivos a los que se les hará commit.
  • squash, que es tomar un commit o más commits y convertirlos en uno solo.
  • work tree, working tree, main working tree, que básicamente es tu versión del proyecto.
  • untracked, staged, tracked. En un proyecto nuevo comienzas con archivos que están untracked, después los pasas al área de staging y cuando haces un commit de los archivos en staging, los archivos están registrados tracked en Git y comenzará el registro de historia.

Clasificando los comando Git en dos.

Los comandos en Git se pueden clasificar básicamente en dos tipos: los de porcelana o de alto nivel y los de plomería o de bajo nivel.