8.1 Personalización de Git - Configuración de Git

Por defecto, Git utiliza cualquier editor que hayas configurado como editor de texto por defecto de tu sistema ($VISUAL o $EDITOR). O, si no lo has configurado, utilizará vi como editor para crear y editar las etiquetas y mensajes de tus confirmaciones de cambio (commit). Para cambiar ese comportamiento, puedes utilizar el ajuste core.editor:

A partir de ese comando, por ejemplo, git lanzará Emacs cada vez que vaya a editar mensajes; indistintamente del editor configurado en la línea de comandos (shell) del sistema.

Si preparas este ajuste para apuntar a un archivo concreto de tu sistema, Git lo utilizará como mensaje por defecto cuando hagas confirmaciones de cambio. Por ejemplo, imagina que creas una plantilla en ~/.gitmessage.txt con un contenido tal como:

Para indicar a Git que lo utilice como mensaje por defecto y que aparezca en tu editor cuando lances el comando git commit, tan solo has de ajustar commit.template:

A partir de entonces, cada vez que confirmes cambios (commit), tu editor se abrirá con algo como esto:

Si tienes una política concreta con respecto a los mensajes de confirmación de cambios, puedes aumentar las posibilidades de que sea respetada si creas una plantilla acorde a dicha política y la pones como plantilla por defecto de Git.

El parámetro core.pager selecciona el paginador utilizado por Git cuando muestra resultados de comandos tales como log o diff.. Puedes ajustarlo para que utilice more o tu paginador favorito, (por defecto, se utiliza less); o puedes anular la paginación si le asignas una cadena vacía.

Si lanzas esto, Git mostrará siempre el resultado completo de todos los comandos, independientemente de lo largo que sea éste.

Si tienes costumbre de firmar tus etiquetas (tal y como se ha visto en Firmando tu trabajo), configurar tu clave de firma GPG puede facilitarte la labor. Puedes configurar tu clave ID de esta forma:

Ahora podrás firmar etiquetas sin necesidad de indicar tu clave cada vez en el comando git tag.

Se pueden indicar expresiones regulares en el archivo .gitignore de tu proyecto para indicar a Git lo que debe considerar o no como archivos sin seguimiento, o lo que interará o no seleccionar cuando lances el comando git add, tal y como se indicó en Ignorar Archivos.

Pero a veces, necesitas ignorar ciertos archivos en todos los repositorios con los que trabajas. Por ejemplo, si trabajas en una computadora con Mac OS X, estarás al tanto de la existencia de los archivo .DS_Store. O si usas Emacs o Vim, también conocerás los archivos terminados en ~.

Este ajuste puedes grabarlo en un archivo global, llamado ~/.gitignore_global, con estos contenidos:

…y si ahora lanzas git config --global core.excludesfile ~/.gitignore_global, Git ya nunca más tendrá en cuenta esos archivos en tus repositorios.

Si te equivocas al teclear un comando de Git, te mostrará algo como:

Git intenta imaginar qué es lo que querías escribir, pero aun así no lo intenta ejecutar. Si pones la opción help.autocorrect a 1, Git sí lanzará el comando corrigiendo tu error:

Observa lo de “0.1 seconds”. Es un entero que representa décimas de segundo. Si le das un valor 50, Git retrasará la ejecución final del comando 5 segundos con el fin de que puedas abortar la operación auto-corregida con la opción help.autocorrect.

Si se lo pides, Git coloreará automáticamente la mayor parte de los resultados que muestre. Puedes ajustar con precisión cada una de las partes a colorear; pero si deseas activar de un golpe todos los colores por defecto, no tienes más que poner a "true" el parámetro color.ui.

Para desactivar totalmente los colores, puedes hacer esto:

El valor predeterminado es auto, que colorea la salida cuando va a un terminal, pero no lo hace cuando se envía la salida a un archivo o a una tubería.

También puedes ponerlo a always para hacer que se coloree siempre. Es muy raro que quieras hacer esto, ya que cuando se quiere puntualmente colorear la salida redirigida se puede pasar un flag --color al comando Git.

Cuando quieras ajustar específicamente, comando a comando, donde colorear y cómo colorear, puedes emplear los ajustes particulares de color. Cada uno de ellos puede fijarse a true (verdadero), false (falso) o always (siempre):

Además, cada uno de ellos tiene parámetros adicionales para asignar colores a partes específicas, por si quieres precisar aún más. Por ejemplo, para mostrar la meta-información del comando diff con letra azul sobre fondo negro y con caracteres en negrita, puedes indicar:

Puedes ajustar un color a cualquiera de los siguientes valores: normal, black (negro), red (rojo), green (verde), yellow (amarillo), blue (azul), magenta, cyan (cian), o white (blanco).

También puedes aplicar atributos tales como bold (negrita), dim (tenue), ul (subrayado), blink (parpadeante) y reverse(video inverso).

Si estás programando en Windows o utilizando algún otro sistema, pero colaborando con gente que programa en Windows. Es muy posible que alguna vez te topes con problemas de finales de línea. Esto se debe a que Windows utiliza retorno-de-carro y salto-de-linea para marcar los finales de línea de sus archivos. Mientras que Mac y Linux utilizan solamente el carácter de salto-de-linea. Esta es una sutil, pero molesta, diferencia cuando se trabaja en entornos multi-plataforma.

Git la maneja convirtiendo automáticamente los finales CRLF en LF al hacer confirmaciones de cambios (commit); y, viceversa, al extraer código (checkout) a la carpeta de trabajo. Puedes activar esta funcionalidad con el parámetro core.autocrlf. Si estás trabajando en una máquina Windows, ajustalo a true, para convertir finales LF en CRLF cuando extraigas código (checkout), puedes hacer esto:

Si estás trabajando en una máquina Linux o Mac, entonces no te interesa convertir automáticamente los finales de línea al extraer código, sino que te interesa arreglar los posibles CRLF que pudieran aparecer accidentalmente. Puedes indicar a Git que convierta CRLF en LF al confirmar cambios (commit), pero no en el otro sentido; utilizando también el parámetro core.autocrlf:

Este ajuste dejará los finales de línea CRLF en las extracciones de código (checkout), pero dejará los finales LF en sistemas Mac o Linux, y en el repositorio.

Si eres un programador Windows, trabajando en un entorno donde solo haya máquinas Windows, puedes desconectar esta funcionalidad, para almacenar CRLFs en el repositorio. Ajustando el parámero a false:

Git viene preajustado para detectar y resolver algunos de los problemas más típicos relacionados con los espacios en blanco. Puede vigilar acerca de seis tipos de problemas de espaciado: tres los tiene activados por defecto, pero se pueden desactivar; y tres vienen desactivados por defecto, pero se pueden activar.

Los que están activos de forma predeterminada son blank-at-eol, que busca espacios al final de la línea; blank-at-eof, que busca líneas en blanco al final del archivo y espace-before-tab, que busca espacios delante de las tabulaciones al comienzo de una línea.

Los que están inactivos de forma predeterminada son ident-with-non-tab, que busca líneas que empiezan con espacios en blanco en lugar de tabulaciones (y se controla con la opción tabwidth); tab-in-indent, que busca tabulaciones en el trozo indentado de una línea; y cr-at-eol, que informa a Git de que los CR al final de las líneas son correctos.

Puedes decir a Git cuales de ellos deseas activar o desactivar, ajustando el parámetro core.whitespace con los valores on/off separados por comas. Puedes desactivarlos tanto dejándolos fuera de la cadena de ajustes, como añadiendo el prefijo - delante del valor. Por ejemplo, si deseas activar todos menos cr-at-eol puedes lanzar:

Git detectará posibles problemas cuando lance un comando git diff, e intentará destacarlos en otro color para que puedas corregirlos antes de confirmar cambios (commit). También pueden ser útiles estos ajustes cuando estás incorporando parches con git apply. Al incorporar parches, puedes pedirle a Git que te avise específicamente sobre determinados problemas de espaciado:

O puedes pedirle que intente corregir automáticamente los problemas antes de aplicar el parche:

Estas opciones se pueden aplicar también al comando git rebase. Si has confirmado cambios con problemas de espaciado, pero no los has enviado (push) aún "aguas arriba" (upstream). Puedes realizar una reorganización (rebase) con la opción --whitespace=fix para que Git corrija automáticamente los problemas según va reescribiendo los parches.

Por defecto, Git no suele comprobar la consistencia de todos los objetos que recibe durante un envío (push), aunque Git tiene la capacidad para asegurarse de que cada objeto sigue casando con su suma de control SHA-1 y sigue apuntando a objetos válidos. No lo suele hacer en todos y cada uno de los envíos (push). Es una operación costosa, que, dependiendo del tamaño del repositorio, puede llegar a añadir mucho tiempo a cada operación de envío (push). De todas formas, si deseas que Git compruebe la consistencia de todos los objetos en todos los envíos, puedes forzarle a hacerlo ajustando a true el parámetro receive.fsckObjects:

A partir de ese momento, Git comprobará la integridad del repositorio antes de aceptar ningún envío (push), para asegurarse de que no está introduciendo datos corruptos.

Si reorganizas (rebase) confirmaciones de cambio (commit) que ya habías enviado y tratas de enviarlas (push) de nuevo; o si intentas enviar una confirmación a una rama remota que no contiene la confirmación actualmente apuntada por la rama, normalmente, la operación te será denegada por la rama remota sobre la que pretendías realizarla. Habitualmente, este es el comportamiento más adecuado. Pero, en el caso de las reorganizaciones, cuando estás totalmente seguro de lo que haces, puedes forzar el envío, utilizando la opción -f en el comando git push a la rama remota.

Para impedir estos envíos forzados de referencias de avance no directo (no fast-forward) a ramas remotas, es para lo que se emplea el parámetro receive.denyNonFastForwards:

Otra manera de obtener el mismo resultado, es a través de los enganches (hooks) en el lado servidor, enganches de los que hablaremos en breve. Esta otra vía te permite realizar ajustes más finos, tales como denegar referencias de avance no directo, (non-fast-forwards), únicamente a un grupo de usuarios.

Uno de los cortocircuitos que suelen utilizar los usuarios para saltarse la politica de denyNonFastForwards, suele ser el borrar la rama y luego volver a enviarla de vuelta con la nueva referencia. Puedes evitar esto poniendo a true el parámetro receive.denyDeletes:

Esto impide el borrado de ramas o de etiquetas por medio de un envío a través de la mesa (push across the board), --ningún usuario lo podrá hacer--. Para borrar ramas remotas, tendrás que borrar los archivos de referencia manualmente sobre el propio servidor. Existen también algunas otras maneras más interesantes de hacer esto mismo, pero para usuarios concretos, a través de permisos (ACLs); tal y como veremos en Un ejemplo de implantación de una determinada política en Git.