Git desde Cero: Personalizar la configuración de Git.

Bienvenidos a un nuevo capítulo de Git desde cero en este curso hablaremos sobre como personalizar la configuración de git. Pondremos colores en nuestro terminal que funcionan para representar cambios, colores en el log, alias de comandos, entre otros detalles. Por ser un curso un poco distinto no nos enfocaremos en comandos particulares sino más bien en el archivo .gitconfig que se encuentra en el $HOME del usuario.

Configuración de git push

Posterior a la versión 1.7.11 de git, se introdujeron cambios en la manera como git realiza push y requiere que se escoja una opción por defecto. En este momento existen cinco (5) maneras diferentes para trabajar con el comando push que son: “nothing”, “current”, “upstream”, “matching” y “simple”.

Nothing: Utilizando esta opción por defecto el comando git push no subirá nada.
Current: Utilizando current por defecto se subirán los cambios a una rama remota que tenga el mismo nombre que la rama local. Es decir: si, estamos trabajando sobre una rama llamada hola-mundo y hacemos git push de los cambios que tengamos locales, se subirán a una rama en el repositorio remoto con el mismo nombre, sino existe, creará la rama.
Upstream: Referencia la rama remota con la local. Estas no tienen porqué tener el mismo nombre para subir los cambios.
Simple: Funciona de la misma manera que upstream pero se niega completamente a subir la información si la rama que está en el repositorio remoto no existe o no se llama igual que la local.
Matching: Absolutamente todas las ramas deben tener el mismo nombre en los dos extremos, es decir, tanto local como remoto. Si se crea una rama local se creará remota también.

nota: Como preferencia personal globalmente utilizo Current ya que se adapta más a mi manera de trabajar. En todo caso, sería adecuado que vayan probando cual les funciona mejor ya que todas las opciones son interesantes.

¿Cómo coloco una opción de estas por defecto?

Es bastante, se podría colocar una global o una local (para un proyecto específico) de la siguiente manera.

$ git config --global push.default current
# De manera local en un proyecto específico.
$ git config --local push.default upstream

Todas configuraciones globales se escriben en un archivo en el “$HOME” del usuario que tiene siempre el mismo nombre y se llama .gitconfig es “oculto”.

Por otro lado las configuraciones locales de proyecto se escriben en la carpeta .git dentro de un archivo que se llama config, este archivo es el mismo que contiene las referencias a las ramas remotas y configuraciones del proyecto, etc.

Configuración de git pull

Normalmente cuando utilizamos git pull sobre una rama, ésta realiza dos funciones git fetch y git merge ésta última puede ocasionar conflictos que debemos solucionar y posteriormente unirlos a mano con otro merge agregando información que no aporta nada al historial del proyecto. Por esta razón es recomendable, que de requerir realizar un pull se emplee el comando rebase en vez del merge de manera directa. Para realizar esto debemos cambiar la configuración por defecto de git o utilizar git pull --rebase cada vez que se quieran descargar “actualizaciones” del servidor remoto. Como manera más practica cambiemos la configuración por defecto

$ git config --global --bool pull.rebase true

De requerir volver a un simple merge por una ocasión específica se puede emplear el comando git pull --no-rebasey listo.

Configurando alias a comandos.

De la misma manera que los sistemas operativos *nix tienen una utilidad llamada alias para colocar un nombre alternativo a archivos, comandos, direcciones, etc.. Git también lo incorpora, pero de manera específica para sus comandos.

¿Para qué podemos utilizar los alias?

Si se están preguntando en que caso particular se puede utilizar esta utilidad, mi respuesta directa sería, en aquellos comandos que utilizan frecuentemente o que realmente son complicados de escribir cuando se necesitan. Como ejemplo crearemos alias a tres (3) comandos altamente utilizados.

git status
git checkout
git log --pretty=format:'%h - %an, %ar - %s' --graph

Para el status utilizaremos la abreviación st, para checkout como co y el log como lg.

$ git config --global alias.st status

$ git config --global alias.co checkout

$ git config --global alias.lg "log --pretty=format:'%h - %an, %ar : %s' --graph"

Ahora si reiniciamos el Terminal con bash -l, exec $SHELL -l o simplemente cerrando y abriendo uno. los tendremos funcionando.

Como había dicho más arriba si realizamos una lectura del archivo .gitconfig podremos ver como está estructurado el mismo.

$ cat ~/.gitconfig
[alias]
    co = checkout
    st = status
    lg = log --pretty=format:'%h - %an, %ar : %s' --graph
[core]
    editor = subl -w
[user]
    name = albertogg
    email = example@gmail.com
[push]
    default = current
[pull]
    rebase = true

De manera muy sencilla se puede entender para que funciona cada etiqueta del archivo.

Configurando colores en el terminal.

Si tienen un terminal con ZSH con oh-my-zsh o su alternativa en Bash seguramente te gustan los colores, la personalización del terminal y estoy seguro que vas a poder observar colores por defecto cuando empleemos las opciones que te vamos a enseñar!

¿Cómo le pongo colores a un status o a un log?

Existen dos maneras claves, si lo que quieres ver son un par de colores y no te importa mucho, puedes dejar las opciones por defecto que te mostraremos a continuación, pero si quieres que el terminal vomite un arcoiris cuando escribas status o log te llevará un poco más de tiempo pero es igualmente sencillo.

Primero para utilizar los colores que git nos proporciona por defecto debemos incluir esta opción git config --global color.ui true. Luego de manera específica agregar que comandos queremos “colorear”.

$ git config --global color.ui true
$ git config --global color.status auto
$ git config --global color.log auto.

A partir de este momento cuando empleemos estos comandos se representarán las modificaciones en el status con colores rojo y verde. Por otro lado el log tendrá algo de amarillo en los títulos.

De los colores que nos ofrece git como el “estandar” u opción por defecto también los podemos personalizarlos de la siguiente manera:

$ git config color.status.changed green
$ git config color.status.untracked cyan

Esto cambiará el color de los archivos modificados a verde y de los archivos que git no sigue en cyan.

Si queremos representar todo el texto con un color diferente en cualquier sección, podríamos crear un alias en conjunto con los colores, algo como:

$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Ten en cuenta que git es altamente personalizable y más cuando mezclamos nuestros conocimientos con un poco de ayuda del internet.

Conclusión

En este último capítulo y en conjunto con los cursos anteriores hemos adquirido el conocimiento necesario para configurar y personalizar git a la medida vale la pena si quieren indagar un poco más sobre este tema que revisen el manual git config -h y busquen por internet. Si te surge algún tipo de duda no te detengas y déjanos un comentario, que gustosamente lo responderemos.

¡Hasta la semana entrante!