ℹ️ Skipped - page is already crawled
| Filter | Status | Condition | Details |
|---|---|---|---|
| HTTP status | PASS | download_http_code = 200 | HTTP 200 |
| Age cutoff | PASS | download_stamp > now() - 6 MONTH | 0.1 months ago |
| History drop | PASS | isNull(history_drop_reason) | No drop reason |
| Spam/ban | PASS | fh_dont_index != 1 AND ml_spam_score = 0 | ml_spam_score=0 |
| Canonical | PASS | meta_canonical IS NULL OR = '' OR = src_unparsed | Not set |
| Property | Value |
|---|---|
| URL | https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git |
| Last Crawled | 2026-04-11 15:25:26 (1 day ago) |
| First Indexed | 2015-07-25 00:02:22 (10 years ago) |
| HTTP Status Code | 200 |
| Meta Title | Git - Configuración de Git |
| Meta Description | null |
| Meta Canonical | null |
| Boilerpipe Text | Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la
manera de utilizarlo; además de haber presentado una serie de herramientas
suministradas con Git para ayudarnos a usarlo de manera sencilla y eficiente.
En este capítulo, avanzaremos sobre ciertas operaciones que puedes utilizar
para personalizar el funcionamiento de Git ; presentando algunos de sus
principales ajustes y el sistema de anclajes (hooks). Con estas operaciones,
será fácil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo
necesitéis.
Como se ha visto brevemente en
[ch01-introduction]
, podemos acceder a los
ajustes de configuración de Git a través del comando
git config
. Una de las
primeras acciones que has realizado con Git ha sido el configurar tu nombre
y tu dirección de correo electrónico.
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Ahora vas a aprender un puñado de nuevas e interesantes opciones que puedes
utilizar para personalizar el uso de Git.
Primeramente, vamos a repasar brevemente los detalles de configuración de Git
que ya has visto. Para determinar su comportamiento no estándar, Git emplea
una serie de archivos de configuración. El primero de ellos es el archivo
/etc/gitconfig
, que contiene valores para todos y cada uno de los usuarios en
el sistema y para todos sus repositorios. Con la opción
--system
del comando
git config
, puedes leer y escribir de/a este archivo.
El segundo es el archivo
~/.gitconfig
(o
~/.config/git/config
), específico
para cada usuario. Con la opción
--global
,
git config
lee y escribe en
este archivo.
Y por último, Git también puede considerar valores de configuración presentes
en el archivo
.git/config
de cada repositorio que estés utilizando. Estos
valores se aplicarán únicamente a dicho repositorio.
Cada nivel sobreescribe los valores del nivel anterior; es decir lo configurado
en
.git/config
tiene preferencia con respecto a lo configurado en
/etc/gitconfig
, por ejemplo.
Nota
Los archivos de configuración de Git son de texto plano, por lo que también
puedes ajustar manualmente los valores de configuración, editando directamente
los archivos correspondientes y escribiendo en ellos con la sintaxis
correspondiente; pero suele ser más sencillo hacerlo siempre a través del
comando
git config
.
Configuración básica del cliente
Las opciones de configuración reconocidas por Git pueden distribuirse en dos
grandes categorías: las del lado cliente y las del lado servidor. La mayoría
de las opciones están en el lado cliente, – configurando tus preferencias
personales de trabajo –. Aunque hay multitud de ellas, aquí vamos a ver
solamente unas pocas, las más comúnmente utilizadas o las que afectan
significativamente a tu forma de trabajar. No vamos a revisar aquellas opciones
utilizadas solo en casos muy especiales. Si quieres consultar una lista
completa, con todas las opciones contempladas en tu versión de Git, puedes
lanzar el comando:
$ man git-config
Este comando muestra todas las opciones con cierto nivel de detalle. También
puedes encontrar esta información de referencia en
https://git-scm.com/docs/git-config.html
.
core.editor
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
:
$ git config --global core.editor emacs
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.
commit.template
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:
subject line
what happened
[ticket: X]
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
:
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
A partir de entonces, cada vez que confirmes cambios (commit), tu editor se
abrirá con algo como esto:
subject line
what happened
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
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.
$ git config --global core.pager ''
Si lanzas esto, Git mostrará siempre el resultado completo de todos los
comandos, independientemente de lo largo que sea éste.
user.signingkey
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:
$ git config --global user.signingkey <gpg-key-id>
Ahora podrás firmar etiquetas sin necesidad de indicar tu clave cada vez en el
comando
git tag
.
$ git tag -s <tag-name>
core.excludesfile
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:
*~
.DS_Store
…y si ahora lanzas
git config --global core.excludesfile ~/.gitignore_global
,
Git ya nunca más tendrá en cuenta esos archivos en tus repositorios.
help.autocorrect
Si te equivocas al teclear un comando de Git, te mostrará algo como:
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
Did you mean this?
checkout
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:
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
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
.
Colores en Git
Git puede marcar con colores los resultados que muestra en tu terminal,
ayudándote así a leerlos más fácilmente. Hay unos cuantos parámetros que te
pueden ayudar a configurar tus colores favoritos.
color.ui
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:
$ git config --global color.ui false
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.
color.*
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):
color.branch
color.diff
color.interactive
color.status
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:
$ git config --global color.diff.meta "blue black bold"
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).
Herramientas externas para fusión y diferencias
Aunque Git lleva una implementación interna de “diff”, la que se utiliza
habitualmente, se puede sustituir por una herramienta externa. Puedes
incluso configurar una herramienta gráfica para la resolución de
conflictos, en lugar de resolverlos manualmente. Vamos a demostrarlo
configurando Perforce Visual Merge (P4Merge) como herramienta para realizar
las comparaciones y resolver conflictos; ya que es una buena herramienta
gráfica y es libre.
Si lo quieres probar, P4Merge funciona en todas las principales plataformas.
Los nombres de carpetas que utilizaremos en los ejemplos funcionan en sistemas
Mac y Linux; para Windows, tendrás que sustituir
/usr/local/bin
por el
correspondiente camino al ejecutable en tu sistema.
Para empezar, tienes que preparar los correspondientes scripts para lanzar
tus comandos. En estos ejemplos, vamos a utilizar caminos y nombres Mac para
los ejecutables; en otros sistemas, tendrás que sustituirlos por los
correspondientes donde tengas instalado
p4merge
. El primer script a
preparar es uno al que denominaremos
extMerge
, para llamar al ejecutable con
los correspondientes argumentos:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
El script para el comparador, ha de asegurarse de recibir siete argumentos
y de pasar dos de ellos al script de fusión (merge). Por defecto, Git pasa los
siguientes argumentos al programa diff (comparador):
path old-file old-hex old-mode new-file new-hex new-mode
Ya que solo necesitarás
old-file
y
new-file
, puedes utilizar el siguiente
script para extraerlos:
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
Además has de asegurarte de que estas herramientas son ejecutables:
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
Una vez preparado todo esto, puedes ajustar el archivo de configuración
para utilizar tus herramientas personalizadas de comparación y
resolución de conflictos. Tenemos varios parámetros a ajustar:
merge.tool
para indicar a Git la estrategia que ha de usar,
mergetool.*.cmd
para especificar como lanzar el comando,
mergetool.trustExitCode
para decir a Git si el código de salida del
programa indica una fusión con éxito o no, y
diff.external
para decir a
Git qué comando lanzar para realizar comparaciones. Es decir, has de
ejecutar cuatro comandos de configuración:
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
o puedes editar tu archivo
~/.gitconfig
para añadirle las siguientes
líneas:
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
Tras ajustar todo esto, si lanzas comandos tales como:
$ git diff 32d1776b1^ 32d1776b1
En lugar de mostrar las diferencias por línea de comandos, Git
lanzará P4Merge, que tiene un aspecto como:
Figura 143. P4Merge.
Si intentas fusionar (merge) dos ramas y tienes los consabidos
conflictos de integración, puedes lanzar el comando
git mergetool
que a su vez
lanzará P4Merge para ayudarte a resolver los conflictos por medio
de su interfaz gráfica.
Lo bonito de estos ajustes con scripts, es que puedes cambiar
fácilmente tus herramientas de comparación (diff) y de fusión (merge).
Por ejemplo, para cambiar tus scripts
extDiff
y
extMerge
para
utilizar KDiff3, tan solo has de editar el archivo
extMerge
:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
A partir de ahora, Git utilizará la herramienta KDiff3 para mostrar
y resolver conflictos de integración.
Git viene preparado para utilizar bastantes otras herramientas de resolución de conflictos, sin necesidad de andar ajustando la configuración. Para listar las herramientas soportadas solo has de lanzar el comando:
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
Si no te interesa utilizar KDiff3 para comparaciones, sino que
tan solo te interesa utilizarlo para resolver conflictos de
integración; teniendo kdiff3 en el path de ejecución, solo has de
lanzar el comando:
$ git config --global merge.tool kdiff3
Si utilizas este comando en lugar de preparar los archivos
extMerge
y
extDiff
antes comentados, Git utilizará KDiff3 para resolución
de conflictos de integración y la herramienta estándar “diff” para
las comparaciones.
Formateo y espacios en blanco
El formato y los espacios en blanco son la fuente de los problemas
más sutiles y frustrantes que muchos desarrolladores se pueden
encontrar en entornos colaborativos, especialmente si son
multi-plataforma. Es muy fácil que algunos parches u otro trabajo
recibido introduzcan sutiles cambios de espaciado, porque los editores
suelen hacerlo inadvertidamente o, trabajando en entornos
multi-plataforma, porque programadores Windows suelen añadir retornos
de carro al final de las lineas que tocan. Git dispone de algunas
opciones de configuración para ayudarnos con estos problemas.
core.autocrlf
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:
$ git config --global core.autocrlf true
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
:
$ git config --global core.autocrlf input
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 config --global core.autocrlf false
core.whitespace
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 config --global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
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:
$ git apply --whitespace=warn <patch>
O puedes pedirle que intente corregir automáticamente los problemas
antes de aplicar el parche:
$ git apply --whitespace=fix <patch>
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.
Configuración del servidor
No hay tantas opciones de configuración en el lado servidor de Git,
pero hay unas pocas interesantes que merecen ser tenidas en cuenta.
receive.fsckObjects
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
:
$ git config --system receive.fsckObjects true
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.
receive.denyNonFastForwards
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
:
$ git config --system receive.denyNonFastForwards true
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.
receive.denyDeletes
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
:
$ git config --system receive.denyDeletes true
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
. |
| Markdown | [](https://git-scm.com/) \--distributed-is-the-new-centralized
- [About](https://git-scm.com/about)
- [Trademark](https://git-scm.com/about/trademark)
- [Learn](https://git-scm.com/learn)
- [Book](https://git-scm.com/book)
- [Cheat Sheet](https://git-scm.com/cheat-sheet)
- [Videos](https://git-scm.com/videos)
- [External Links](https://git-scm.com/doc/ext)
- [Tools](https://git-scm.com/tools)
- [Command Line](https://git-scm.com/tools/command-line)
- [GUIs](https://git-scm.com/tools/guis)
- [Hosting](https://git-scm.com/tools/hosting)
- [Reference](https://git-scm.com/docs)
- [Install](https://git-scm.com/install/linux)
- [Community](https://git-scm.com/community)
***
This book is available in [English](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
Full translation available in
| |
|---|
| [azərbaycan dili](https://git-scm.com/book/az/v2/Git%E2%80%99i-F%C9%99rdil%C9%99%C5%9Fdirm%C9%99k-Git-Konfiqurasiyas%C4%B1), |
| [български език](https://git-scm.com/book/bg/v2/Git-%D0%BD%D0%B0-%D0%BD%D0%B8%D1%81%D0%BA%D0%BE-%D0%BD%D0%B8%D0%B2%D0%BE-Plumbing-%D0%B8-Porcelain-%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B8), |
| [Deutsch](https://git-scm.com/book/de/v2/Git-einrichten-Git-Konfiguration), |
| [Español](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git), |
| [فارسی](https://git-scm.com/book/fa/v2/%D8%B3%D9%81%D8%A7%D8%B1%D8%B4%DB%8C%E2%80%8C%D8%B3%D8%A7%D8%B2%DB%8C-Git-Customizing-Git-%D9%BE%DB%8C%DA%A9%D8%B1%D8%A8%D9%86%D8%AF%DB%8C-%DA%AF%DB%8C%D8%AA-Git-Configuration), |
| [Français](https://git-scm.com/book/fr/v2/Personnalisation-de-Git-Configuration-de-Git), |
| [Ελληνικά](https://git-scm.com/book/gr/v2/%CE%95%CE%BE%CE%B1%CF%84%CE%BF%CE%BC%CE%AF%CE%BA%CE%B5%CF%85%CF%83%CE%B7-%CF%84%CE%BF%CF%85-Git-%CE%94%CE%B9%CE%B1%CE%BC%CF%8C%CF%81%CF%86%CF%89%CF%83%CE%B7-Git), |
| [日本語](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E8%A8%AD%E5%AE%9A), |
| [한국어](https://git-scm.com/book/ko/v2/Git%EB%A7%9E%EC%B6%A4-Git-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0), |
| [Nederlands](https://git-scm.com/book/nl/v2/Git-aanpassen-Git-configuratie), |
| [Русский](https://git-scm.com/book/ru/v2/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-Git-%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D1%8F-Git), |
| [Slovenščina](https://git-scm.com/book/sl/v2/Prilagoditev-Gita-Konfiguracija-Git), |
| [Српски](https://git-scm.com/book/sr/v2/%D0%9F%D1%80%D0%B8%D0%BB%D0%B0%D0%B3%D0%BE%D1%92%D0%B0%D0%B2%D0%B0%D1%9A%D0%B5-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B0-%D0%93%D0%B8%D1%82-%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B8%D1%81%D0%B0%D1%9A%D0%B5-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B0-%D0%93%D0%B8%D1%82), |
| [Svenska](https://git-scm.com/book/sv/v2/Anpassa-Git-Git%E2%80%91konfiguration), |
| [Tagalog](https://git-scm.com/book/tl/v2/Pag-aangkop-sa-Sariling-Pangangailagan-ng-Git-Kompigurasyon-ng-Git), |
| [Türkçe](https://git-scm.com/book/tr/v2/Git%E2%80%99i-%C3%96zelle%C5%9Ftirmek-Git-Yap%C4%B1land%C4%B1rmas%C4%B1). |
| [Українська](https://git-scm.com/book/uk/v2/%D0%9D%D0%B0%D0%BB%D0%B0%D1%88%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F-Git-%D0%9A%D0%BE%D0%BD%D1%84%D1%96%D0%B3%D1%83%D1%80%D0%B0%D1%86%D1%96%D1%8F-Git), |
| [简体中文](https://git-scm.com/book/zh/v2/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-%E9%85%8D%E7%BD%AE-Git), |
Partial translations available in
| |
|---|
| [Čeština](https://git-scm.com/book/cs/v2/Customizing-Git-Git-Configuration), |
| [Македонски](https://git-scm.com/book/mk/v2/%D0%9F%D0%B5%D1%80%D1%81%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%98%D0%B0-%D0%BD%D0%B0-Git-Git-Configuration), |
| [Polski](https://git-scm.com/book/pl/v2/Dostosowywanie-Gita-Konfiguracja-Gita), |
| [Português (Brasil)](https://git-scm.com/book/pt-br/v2/Customizing-Git-Git-Configuration), |
| [Ўзбекча](https://git-scm.com/book/uz/v2/Customizing-Git-Git-Configuration), |
| [繁體中文](https://git-scm.com/book/zh-tw/v2/Customizing-Git-Git-Configuration), |
Translations started for
| |
|---|
| [Беларуская](https://git-scm.com/book/be/v2/Customizing-Git-Git-Configuration), |
| [Indonesian](https://git-scm.com/book/id/v2/Kostumisasi-Git-Konfigurasi-Git), |
| [Italiano](https://git-scm.com/book/it/v2/Customizing-Git-Git-Configuration), |
| [Bahasa Melayu](https://git-scm.com/book/ms/v2/Customizing-Git-Git-Configuration), |
| [Português (Portugal)](https://git-scm.com/book/pt-pt/v2/Personalizar-o-Git-Git-Configuration). |
***
The source of this book is [hosted on GitHub.](https://github.com/progit/progit2-es)
Patches, suggestions and comments are welcome.
[Chapters ▾](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)
1. ## 1\. [Inicio - Sobre el Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)
1. 1\.1 [Acerca del Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)
2. 1\.2 [Una breve historia de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Una-breve-historia-de-Git)
3. 1\.3 [Fundamentos de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git)
4. 1\.4 [La Línea de Comandos](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-La-L%C3%ADnea-de-Comandos)
5. 1\.5 [Instalación de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Instalaci%C3%B3n-de-Git)
6. 1\.6 [Configurando Git por primera vez](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Configurando-Git-por-primera-vez)
7. 1\.7 [¿Cómo obtener ayuda?](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda%3F)
8. 1\.8 [Resumen](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Resumen)
2. ## 2\. [Fundamentos de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)
1. 2\.1 [Obteniendo un repositorio Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)
2. 2\.2 [Guardando cambios en el Repositorio](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio)
3. 2\.3 [Ver el Historial de Confirmaciones](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones)
4. 2\.4 [Deshacer Cosas](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Deshacer-Cosas)
5. 2\.5 [Trabajar con Remotos](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Trabajar-con-Remotos)
6. 2\.6 [Etiquetado](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Etiquetado)
7. 2\.7 [Alias de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Alias-de-Git)
8. 2\.8 [Resumen](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Resumen)
3. ## 3\. [Ramificaciones en Git](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)
1. 3\.1 [¿Qué es una rama?](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)
2. 3\.2 [Procedimientos Básicos para Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar)
3. 3\.3 [Gestión de Ramas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Gesti%C3%B3n-de-Ramas)
4. 3\.4 [Flujos de Trabajo Ramificados](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados)
5. 3\.5 [Ramas Remotas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas)
6. 3\.6 [Reorganizar el Trabajo Realizado](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado)
7. 3\.7 [Recapitulación](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Recapitulaci%C3%B3n)
4. ## 4\. [Git en el Servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos)
1. 4\.1 [Los Protocolos](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos)
2. 4\.2 [Configurando Git en un servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-Git-en-un-servidor)
3. 4\.3 [Generando tu clave pública SSH](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH)
4. 4\.4 [Configurando el servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-el-servidor)
5. 4\.5 [El demonio Git](https://git-scm.com/book/es/v2/Git-en-el-Servidor-El-demonio-Git)
6. 4\.6 [HTTP Inteligente](https://git-scm.com/book/es/v2/Git-en-el-Servidor-HTTP-Inteligente)
7. 4\.7 [GitWeb](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitWeb)
8. 4\.8 [GitLab](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitLab)
9. 4\.9 [Git en un alojamiento externo](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Git-en-un-alojamiento-externo)
10. 4\.10 [Resumen](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Resumen)
5. ## 5\. [Git en entornos distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)
1. 5\.1 [Flujos de trabajo distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)
2. 5\.2 [Contribuyendo a un Proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto)
3. 5\.3 [Manteniendo un proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Manteniendo-un-proyecto)
4. 5\.4 [Resumen](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Resumen)
1. ## 6\. [GitHub](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)
1. 6\.1 [Creación y configuración de la cuenta](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)
2. 6\.2 [Participando en Proyectos](https://git-scm.com/book/es/v2/GitHub-Participando-en-Proyectos)
3. 6\.3 [Mantenimiento de un proyecto](https://git-scm.com/book/es/v2/GitHub-Mantenimiento-de-un-proyecto)
4. 6\.4 [Gestión de una organización](https://git-scm.com/book/es/v2/GitHub-Gesti%C3%B3n-de-una-organizaci%C3%B3n)
5. 6\.5 [Scripting en GitHub](https://git-scm.com/book/es/v2/GitHub-Scripting-en-GitHub)
6. 6\.6 [Resumen](https://git-scm.com/book/es/v2/GitHub-Resumen)
2. ## 7\. [Herramientas de Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)
1. 7\.1 [Revisión por selección](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)
2. 7\.2 [Organización interactiva](https://git-scm.com/book/es/v2/Herramientas-de-Git-Organizaci%C3%B3n-interactiva)
3. 7\.3 [Guardado rápido y Limpieza](https://git-scm.com/book/es/v2/Herramientas-de-Git-Guardado-r%C3%A1pido-y-Limpieza)
4. 7\.4 [Firmando tu trabajo](https://git-scm.com/book/es/v2/Herramientas-de-Git-Firmando-tu-trabajo)
5. 7\.5 [Buscando](https://git-scm.com/book/es/v2/Herramientas-de-Git-Buscando)
6. 7\.6 [Reescribiendo la Historia](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reescribiendo-la-Historia)
7. 7\.7 [Reiniciar Desmitificado](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado)
8. 7\.8 [Fusión Avanzada](https://git-scm.com/book/es/v2/Herramientas-de-Git-Fusi%C3%B3n-Avanzada)
9. 7\.9 [Rerere](https://git-scm.com/book/es/v2/Herramientas-de-Git-Rerere)
10. 7\.10 [Haciendo debug con Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Haciendo-debug-con-Git)
11. 7\.11 [Submódulos](https://git-scm.com/book/es/v2/Herramientas-de-Git-Subm%C3%B3dulos)
12. 7\.12 [Agrupaciones](https://git-scm.com/book/es/v2/Herramientas-de-Git-Agrupaciones)
13. 7\.13 [Replace](https://git-scm.com/book/es/v2/Herramientas-de-Git-Replace)
14. 7\.14 [Almacenamiento de credenciales](https://git-scm.com/book/es/v2/Herramientas-de-Git-Almacenamiento-de-credenciales)
15. 7\.15 [Resumen](https://git-scm.com/book/es/v2/Herramientas-de-Git-Resumen)
3. ## 8\. [Personalización de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)
1. 8\.1 [Configuración de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)
2. 8\.2 [Git Attributes](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Git-Attributes)
3. 8\.3 [Puntos de enganche en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Puntos-de-enganche-en-Git)
4. 8\.4 [Un ejemplo de implantación de una determinada política en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Un-ejemplo-de-implantaci%C3%B3n-de-una-determinada-pol%C3%ADtica-en-Git)
5. 8\.5 [Recapitulación](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Recapitulaci%C3%B3n)
4. ## 9\. [Git y Otros Sistemas](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente)
1. 9\.1 [Git como Cliente](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente)
2. 9\.2 [Migración a Git](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Migraci%C3%B3n-a-Git)
3. 9\.3 [Resumen](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Resumen)
5. ## 10\. [Los entresijos internos de Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)
1. 10\.1 [Fontanería y porcelana](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)
2. 10\.2 [Los objetos Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Los-objetos-Git)
3. 10\.3 [Referencias Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Referencias-Git)
4. 10\.4 [Archivos empaquetadores](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Archivos-empaquetadores)
5. 10\.5 [Las especificaciones para hacer referencia a… (refspec)](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Las-especificaciones-para-hacer-referencia-a%E2%80%A6%E2%80%8B-refspec)
6. 10\.6 [Protocolos de transferencia](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Protocolos-de-transferencia)
7. 10\.7 [Mantenimiento y recuperación de datos](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Mantenimiento-y-recuperaci%C3%B3n-de-datos)
8. 10\.8 [Variables de entorno](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Variables-de-entorno)
9. 10\.9 [Recapitulación](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Recapitulaci%C3%B3n)
1. ## A1. [Apéndice A: Git en otros entornos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)
1. A1.1 [Interfaces gráficas](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)
2. A1.2 [Git en Visual Studio](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Visual-Studio)
3. A1.3 [Git en Eclipse](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Eclipse)
4. A1.4 [Git con Bash](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-con-Bash)
5. A1.5 [Git en Zsh](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Zsh)
6. A1.6 [Git en Powershell](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Powershell)
7. A1.7 [Resumen](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Resumen)
2. ## A2. [Apéndice B: Integrando Git en tus Aplicaciones](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)
1. A2.1 [Git mediante Línea de Comandos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)
2. A2.2 [Libgit2](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Libgit2)
3. A2.3 [JGit](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-JGit)
3. ## A3. [Apéndice C: Comandos de Git](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)
1. A3.1 [Configuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)
2. A3.2 [Obtener y Crear Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Obtener-y-Crear-Proyectos)
3. A3.3 [Seguimiento Básico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Seguimiento-B%C3%A1sico)
4. A3.4 [Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Ramificar-y-Fusionar)
5. A3.5 [Compartir y Actualizar Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Compartir-y-Actualizar-Proyectos)
6. A3.6 [Inspección y Comparación](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Inspecci%C3%B3n-y-Comparaci%C3%B3n)
7. A3.7 [Depuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Depuraci%C3%B3n)
8. A3.8 [Parcheo](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Parcheo)
9. A3.9 [Correo Electrónico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Correo-Electr%C3%B3nico)
10. A3.10 [Sistemas Externos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Sistemas-Externos)
11. A3.11 [Administración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Administraci%C3%B3n)
12. A3.12 [Comandos de Fontanería](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Comandos-de-Fontaner%C3%ADa)
2nd Edition
# 8\.1 Personalización de Git - Configuración de Git
Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la manera de utilizarlo; además de haber presentado una serie de herramientas suministradas con Git para ayudarnos a usarlo de manera sencilla y eficiente. En este capítulo, avanzaremos sobre ciertas operaciones que puedes utilizar para personalizar el funcionamiento de Git ; presentando algunos de sus principales ajustes y el sistema de anclajes (hooks). Con estas operaciones, será fácil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo necesitéis.
## Configuración de Git
Como se ha visto brevemente en [\[ch01-introduction\]](https://git-scm.com/book/es/v2/ch00/ch01-introduction), podemos acceder a los ajustes de configuración de Git a través del comando *git config*. Una de las primeras acciones que has realizado con Git ha sido el configurar tu nombre y tu dirección de correo electrónico.
```
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
```
Ahora vas a aprender un puñado de nuevas e interesantes opciones que puedes utilizar para personalizar el uso de Git.
Primeramente, vamos a repasar brevemente los detalles de configuración de Git que ya has visto. Para determinar su comportamiento no estándar, Git emplea una serie de archivos de configuración. El primero de ellos es el archivo `/etc/gitconfig`, que contiene valores para todos y cada uno de los usuarios en el sistema y para todos sus repositorios. Con la opción `--system` del comando `git config`, puedes leer y escribir de/a este archivo.
El segundo es el archivo `~/.gitconfig` (o `~/.config/git/config`), específico para cada usuario. Con la opción `--global`, `git config` lee y escribe en este archivo.
Y por último, Git también puede considerar valores de configuración presentes en el archivo `.git/config` de cada repositorio que estés utilizando. Estos valores se aplicarán únicamente a dicho repositorio.
Cada nivel sobreescribe los valores del nivel anterior; es decir lo configurado en `.git/config` tiene preferencia con respecto a lo configurado en `/etc/gitconfig`, por ejemplo.
| | |
|---|---|
| Nota | Los archivos de configuración de Git son de texto plano, por lo que también puedes ajustar manualmente los valores de configuración, editando directamente los archivos correspondientes y escribiendo en ellos con la sintaxis correspondiente; pero suele ser más sencillo hacerlo siempre a través del comando `git config`. |
### Configuración básica del cliente
Las opciones de configuración reconocidas por Git pueden distribuirse en dos grandes categorías: las del lado cliente y las del lado servidor. La mayoría de las opciones están en el lado cliente, – configurando tus preferencias personales de trabajo –. Aunque hay multitud de ellas, aquí vamos a ver solamente unas pocas, las más comúnmente utilizadas o las que afectan significativamente a tu forma de trabajar. No vamos a revisar aquellas opciones utilizadas solo en casos muy especiales. Si quieres consultar una lista completa, con todas las opciones contempladas en tu versión de Git, puedes lanzar el comando:
```
$ man git-config
```
Este comando muestra todas las opciones con cierto nivel de detalle. También puedes encontrar esta información de referencia en <https://git-scm.com/docs/git-config.html>.
#### `core.editor`
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`:
```
$ git config --global core.editor emacs
```
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.
#### `commit.template`
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:
```
subject line
what happened
[ticket: X]
```
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`:
```
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
```
A partir de entonces, cada vez que confirmes cambios (commit), tu editor se abrirá con algo como esto:
```
subject line
what happened
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
```
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.
#### `core.pager`
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.
```
$ git config --global core.pager ''
```
Si lanzas esto, Git mostrará siempre el resultado completo de todos los comandos, independientemente de lo largo que sea éste.
#### `user.signingkey`
Si tienes costumbre de firmar tus etiquetas (tal y como se ha visto en [Firmando tu trabajo](https://git-scm.com/book/es/v2/ch00/r_signing)), configurar tu clave de firma GPG puede facilitarte la labor. Puedes configurar tu clave ID de esta forma:
```
$ git config --global user.signingkey <gpg-key-id>
```
Ahora podrás firmar etiquetas sin necesidad de indicar tu clave cada vez en el comando `git tag`.
```
$ git tag -s <tag-name>
```
#### `core.excludesfile`
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](https://git-scm.com/book/es/v2/ch00/r_ignoring).
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:
```
*~
.DS_Store
```
…y si ahora lanzas `git config --global core.excludesfile ~/.gitignore_global`, Git ya nunca más tendrá en cuenta esos archivos en tus repositorios.
#### `help.autocorrect`
Si te equivocas al teclear un comando de Git, te mostrará algo como:
```
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
Did you mean this?
checkout
```
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:
```
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
```
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`.
### Colores en Git
Git puede marcar con colores los resultados que muestra en tu terminal, ayudándote así a leerlos más fácilmente. Hay unos cuantos parámetros que te pueden ayudar a configurar tus colores favoritos.
#### `color.ui`
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:
```
$ git config --global color.ui false
```
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.
#### `color.*`
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):
```
color.branch
color.diff
color.interactive
color.status
```
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:
```
$ git config --global color.diff.meta "blue black bold"
```
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).
### Herramientas externas para fusión y diferencias
Aunque Git lleva una implementación interna de “diff”, la que se utiliza habitualmente, se puede sustituir por una herramienta externa. Puedes incluso configurar una herramienta gráfica para la resolución de conflictos, en lugar de resolverlos manualmente. Vamos a demostrarlo configurando Perforce Visual Merge (P4Merge) como herramienta para realizar las comparaciones y resolver conflictos; ya que es una buena herramienta gráfica y es libre.
Si lo quieres probar, P4Merge funciona en todas las principales plataformas. Los nombres de carpetas que utilizaremos en los ejemplos funcionan en sistemas Mac y Linux; para Windows, tendrás que sustituir */usr/local/bin* por el correspondiente camino al ejecutable en tu sistema.
P4Merge se puede descargar desde <https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools>.
Para empezar, tienes que preparar los correspondientes scripts para lanzar tus comandos. En estos ejemplos, vamos a utilizar caminos y nombres Mac para los ejecutables; en otros sistemas, tendrás que sustituirlos por los correspondientes donde tengas instalado *p4merge*. El primer script a preparar es uno al que denominaremos *extMerge*, para llamar al ejecutable con los correspondientes argumentos:
```
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
```
El script para el comparador, ha de asegurarse de recibir siete argumentos y de pasar dos de ellos al script de fusión (merge). Por defecto, Git pasa los siguientes argumentos al programa diff (comparador):
```
path old-file old-hex old-mode new-file new-hex new-mode
```
Ya que solo necesitarás *old-file* y *new-file*, puedes utilizar el siguiente script para extraerlos:
```
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
```
Además has de asegurarte de que estas herramientas son ejecutables:
```
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
```
Una vez preparado todo esto, puedes ajustar el archivo de configuración para utilizar tus herramientas personalizadas de comparación y resolución de conflictos. Tenemos varios parámetros a ajustar: `merge.tool` para indicar a Git la estrategia que ha de usar, `mergetool.*.cmd` para especificar como lanzar el comando, `mergetool.trustExitCode` para decir a Git si el código de salida del programa indica una fusión con éxito o no, y `diff.external` para decir a Git qué comando lanzar para realizar comparaciones. Es decir, has de ejecutar cuatro comandos de configuración:
```
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
```
o puedes editar tu archivo *~/.gitconfig* para añadirle las siguientes líneas:
```
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
```
Tras ajustar todo esto, si lanzas comandos tales como:
```
$ git diff 32d1776b1^ 32d1776b1
```
En lugar de mostrar las diferencias por línea de comandos, Git lanzará P4Merge, que tiene un aspecto como:
Figura 143. P4Merge.
Si intentas fusionar (merge) dos ramas y tienes los consabidos conflictos de integración, puedes lanzar el comando `git mergetool` que a su vez lanzará P4Merge para ayudarte a resolver los conflictos por medio de su interfaz gráfica.
Lo bonito de estos ajustes con scripts, es que puedes cambiar fácilmente tus herramientas de comparación (diff) y de fusión (merge). Por ejemplo, para cambiar tus scripts `extDiff` y `extMerge` para utilizar KDiff3, tan solo has de editar el archivo `extMerge`:
```
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
```
A partir de ahora, Git utilizará la herramienta KDiff3 para mostrar y resolver conflictos de integración.
Git viene preparado para utilizar bastantes otras herramientas de resolución de conflictos, sin necesidad de andar ajustando la configuración. Para listar las herramientas soportadas solo has de lanzar el comando:
```
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
```
Si no te interesa utilizar KDiff3 para comparaciones, sino que tan solo te interesa utilizarlo para resolver conflictos de integración; teniendo kdiff3 en el path de ejecución, solo has de lanzar el comando:
```
$ git config --global merge.tool kdiff3
```
Si utilizas este comando en lugar de preparar los archivos `extMerge` y `extDiff` antes comentados, Git utilizará KDiff3 para resolución de conflictos de integración y la herramienta estándar “diff” para las comparaciones.
### Formateo y espacios en blanco
El formato y los espacios en blanco son la fuente de los problemas más sutiles y frustrantes que muchos desarrolladores se pueden encontrar en entornos colaborativos, especialmente si son multi-plataforma. Es muy fácil que algunos parches u otro trabajo recibido introduzcan sutiles cambios de espaciado, porque los editores suelen hacerlo inadvertidamente o, trabajando en entornos multi-plataforma, porque programadores Windows suelen añadir retornos de carro al final de las lineas que tocan. Git dispone de algunas opciones de configuración para ayudarnos con estos problemas.
#### `core.autocrlf`
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:
```
$ git config --global core.autocrlf true
```
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`:
```
$ git config --global core.autocrlf input
```
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 config --global core.autocrlf false
```
#### `core.whitespace`
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 config --global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
```
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:
```
$ git apply --whitespace=warn <patch>
```
O puedes pedirle que intente corregir automáticamente los problemas antes de aplicar el parche:
```
$ git apply --whitespace=fix <patch>
```
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.
### Configuración del servidor
No hay tantas opciones de configuración en el lado servidor de Git, pero hay unas pocas interesantes que merecen ser tenidas en cuenta.
#### `receive.fsckObjects`
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`:
```
$ git config --system receive.fsckObjects true
```
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.
#### `receive.denyNonFastForwards`
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`:
```
$ git config --system receive.denyNonFastForwards true
```
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.
#### `receive.denyDeletes`
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`:
```
$ git config --system receive.denyDeletes true
```
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](https://git-scm.com/book/es/v2/ch00/r_an_example_git_enforced_policy).
[prev](https://git-scm.com/book/es/v2/Herramientas-de-Git-Resumen) \| [next](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Git-Attributes)
[About this site](https://git-scm.com/site)
Patches, suggestions, and comments are welcome.
Git is a member of [Software Freedom Conservancy](https://git-scm.com/sfc) |
| Readable Markdown | Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la manera de utilizarlo; además de haber presentado una serie de herramientas suministradas con Git para ayudarnos a usarlo de manera sencilla y eficiente. En este capítulo, avanzaremos sobre ciertas operaciones que puedes utilizar para personalizar el funcionamiento de Git ; presentando algunos de sus principales ajustes y el sistema de anclajes (hooks). Con estas operaciones, será fácil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo necesitéis.
Como se ha visto brevemente en [\[ch01-introduction\]](https://git-scm.com/book/es/v2/ch00/ch01-introduction), podemos acceder a los ajustes de configuración de Git a través del comando *git config*. Una de las primeras acciones que has realizado con Git ha sido el configurar tu nombre y tu dirección de correo electrónico.
```
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
```
Ahora vas a aprender un puñado de nuevas e interesantes opciones que puedes utilizar para personalizar el uso de Git.
Primeramente, vamos a repasar brevemente los detalles de configuración de Git que ya has visto. Para determinar su comportamiento no estándar, Git emplea una serie de archivos de configuración. El primero de ellos es el archivo `/etc/gitconfig`, que contiene valores para todos y cada uno de los usuarios en el sistema y para todos sus repositorios. Con la opción `--system` del comando `git config`, puedes leer y escribir de/a este archivo.
El segundo es el archivo `~/.gitconfig` (o `~/.config/git/config`), específico para cada usuario. Con la opción `--global`, `git config` lee y escribe en este archivo.
Y por último, Git también puede considerar valores de configuración presentes en el archivo `.git/config` de cada repositorio que estés utilizando. Estos valores se aplicarán únicamente a dicho repositorio.
Cada nivel sobreescribe los valores del nivel anterior; es decir lo configurado en `.git/config` tiene preferencia con respecto a lo configurado en `/etc/gitconfig`, por ejemplo.
| | |
|---|---|
| Nota | Los archivos de configuración de Git son de texto plano, por lo que también puedes ajustar manualmente los valores de configuración, editando directamente los archivos correspondientes y escribiendo en ellos con la sintaxis correspondiente; pero suele ser más sencillo hacerlo siempre a través del comando `git config`. |
### Configuración básica del cliente
Las opciones de configuración reconocidas por Git pueden distribuirse en dos grandes categorías: las del lado cliente y las del lado servidor. La mayoría de las opciones están en el lado cliente, – configurando tus preferencias personales de trabajo –. Aunque hay multitud de ellas, aquí vamos a ver solamente unas pocas, las más comúnmente utilizadas o las que afectan significativamente a tu forma de trabajar. No vamos a revisar aquellas opciones utilizadas solo en casos muy especiales. Si quieres consultar una lista completa, con todas las opciones contempladas en tu versión de Git, puedes lanzar el comando:
```
$ man git-config
```
Este comando muestra todas las opciones con cierto nivel de detalle. También puedes encontrar esta información de referencia en <https://git-scm.com/docs/git-config.html>.
#### `core.editor`
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`:
```
$ git config --global core.editor emacs
```
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.
#### `commit.template`
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:
```
subject line
what happened
[ticket: X]
```
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`:
```
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
```
A partir de entonces, cada vez que confirmes cambios (commit), tu editor se abrirá con algo como esto:
```
subject line
what happened
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
```
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.
```
$ git config --global core.pager ''
```
Si lanzas esto, Git mostrará siempre el resultado completo de todos los comandos, independientemente de lo largo que sea éste.
#### `user.signingkey`
Si tienes costumbre de firmar tus etiquetas (tal y como se ha visto en [Firmando tu trabajo](https://git-scm.com/book/es/v2/ch00/r_signing)), configurar tu clave de firma GPG puede facilitarte la labor. Puedes configurar tu clave ID de esta forma:
```
$ git config --global user.signingkey <gpg-key-id>
```
Ahora podrás firmar etiquetas sin necesidad de indicar tu clave cada vez en el comando `git tag`.
```
$ git tag -s <tag-name>
```
#### `core.excludesfile`
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](https://git-scm.com/book/es/v2/ch00/r_ignoring).
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:
```
*~
.DS_Store
```
…y si ahora lanzas `git config --global core.excludesfile ~/.gitignore_global`, Git ya nunca más tendrá en cuenta esos archivos en tus repositorios.
#### `help.autocorrect`
Si te equivocas al teclear un comando de Git, te mostrará algo como:
```
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
Did you mean this?
checkout
```
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:
```
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
```
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`.
### Colores en Git
Git puede marcar con colores los resultados que muestra en tu terminal, ayudándote así a leerlos más fácilmente. Hay unos cuantos parámetros que te pueden ayudar a configurar tus colores favoritos.
#### `color.ui`
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:
```
$ git config --global color.ui false
```
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.
#### `color.*`
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):
```
color.branch
color.diff
color.interactive
color.status
```
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:
```
$ git config --global color.diff.meta "blue black bold"
```
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).
### Herramientas externas para fusión y diferencias
Aunque Git lleva una implementación interna de “diff”, la que se utiliza habitualmente, se puede sustituir por una herramienta externa. Puedes incluso configurar una herramienta gráfica para la resolución de conflictos, en lugar de resolverlos manualmente. Vamos a demostrarlo configurando Perforce Visual Merge (P4Merge) como herramienta para realizar las comparaciones y resolver conflictos; ya que es una buena herramienta gráfica y es libre.
Si lo quieres probar, P4Merge funciona en todas las principales plataformas. Los nombres de carpetas que utilizaremos en los ejemplos funcionan en sistemas Mac y Linux; para Windows, tendrás que sustituir */usr/local/bin* por el correspondiente camino al ejecutable en tu sistema.
Para empezar, tienes que preparar los correspondientes scripts para lanzar tus comandos. En estos ejemplos, vamos a utilizar caminos y nombres Mac para los ejecutables; en otros sistemas, tendrás que sustituirlos por los correspondientes donde tengas instalado *p4merge*. El primer script a preparar es uno al que denominaremos *extMerge*, para llamar al ejecutable con los correspondientes argumentos:
```
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
```
El script para el comparador, ha de asegurarse de recibir siete argumentos y de pasar dos de ellos al script de fusión (merge). Por defecto, Git pasa los siguientes argumentos al programa diff (comparador):
```
path old-file old-hex old-mode new-file new-hex new-mode
```
Ya que solo necesitarás *old-file* y *new-file*, puedes utilizar el siguiente script para extraerlos:
```
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
```
Además has de asegurarte de que estas herramientas son ejecutables:
```
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
```
Una vez preparado todo esto, puedes ajustar el archivo de configuración para utilizar tus herramientas personalizadas de comparación y resolución de conflictos. Tenemos varios parámetros a ajustar: `merge.tool` para indicar a Git la estrategia que ha de usar, `mergetool.*.cmd` para especificar como lanzar el comando, `mergetool.trustExitCode` para decir a Git si el código de salida del programa indica una fusión con éxito o no, y `diff.external` para decir a Git qué comando lanzar para realizar comparaciones. Es decir, has de ejecutar cuatro comandos de configuración:
```
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
```
o puedes editar tu archivo *~/.gitconfig* para añadirle las siguientes líneas:
```
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
```
Tras ajustar todo esto, si lanzas comandos tales como:
```
$ git diff 32d1776b1^ 32d1776b1
```
En lugar de mostrar las diferencias por línea de comandos, Git lanzará P4Merge, que tiene un aspecto como:
Figura 143. P4Merge.
Si intentas fusionar (merge) dos ramas y tienes los consabidos conflictos de integración, puedes lanzar el comando `git mergetool` que a su vez lanzará P4Merge para ayudarte a resolver los conflictos por medio de su interfaz gráfica.
Lo bonito de estos ajustes con scripts, es que puedes cambiar fácilmente tus herramientas de comparación (diff) y de fusión (merge). Por ejemplo, para cambiar tus scripts `extDiff` y `extMerge` para utilizar KDiff3, tan solo has de editar el archivo `extMerge`:
```
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
```
A partir de ahora, Git utilizará la herramienta KDiff3 para mostrar y resolver conflictos de integración.
Git viene preparado para utilizar bastantes otras herramientas de resolución de conflictos, sin necesidad de andar ajustando la configuración. Para listar las herramientas soportadas solo has de lanzar el comando:
```
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
```
Si no te interesa utilizar KDiff3 para comparaciones, sino que tan solo te interesa utilizarlo para resolver conflictos de integración; teniendo kdiff3 en el path de ejecución, solo has de lanzar el comando:
```
$ git config --global merge.tool kdiff3
```
Si utilizas este comando en lugar de preparar los archivos `extMerge` y `extDiff` antes comentados, Git utilizará KDiff3 para resolución de conflictos de integración y la herramienta estándar “diff” para las comparaciones.
### Formateo y espacios en blanco
El formato y los espacios en blanco son la fuente de los problemas más sutiles y frustrantes que muchos desarrolladores se pueden encontrar en entornos colaborativos, especialmente si son multi-plataforma. Es muy fácil que algunos parches u otro trabajo recibido introduzcan sutiles cambios de espaciado, porque los editores suelen hacerlo inadvertidamente o, trabajando en entornos multi-plataforma, porque programadores Windows suelen añadir retornos de carro al final de las lineas que tocan. Git dispone de algunas opciones de configuración para ayudarnos con estos problemas.
#### `core.autocrlf`
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:
```
$ git config --global core.autocrlf true
```
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`:
```
$ git config --global core.autocrlf input
```
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 config --global core.autocrlf false
```
#### `core.whitespace`
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 config --global core.whitespace \
trailing-space,space-before-tab,indent-with-non-tab
```
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:
```
$ git apply --whitespace=warn <patch>
```
O puedes pedirle que intente corregir automáticamente los problemas antes de aplicar el parche:
```
$ git apply --whitespace=fix <patch>
```
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.
### Configuración del servidor
No hay tantas opciones de configuración en el lado servidor de Git, pero hay unas pocas interesantes que merecen ser tenidas en cuenta.
#### `receive.fsckObjects`
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`:
```
$ git config --system receive.fsckObjects true
```
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.
#### `receive.denyNonFastForwards`
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`:
```
$ git config --system receive.denyNonFastForwards true
```
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.
#### `receive.denyDeletes`
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`:
```
$ git config --system receive.denyDeletes true
```
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](https://git-scm.com/book/es/v2/ch00/r_an_example_git_enforced_policy). |
| Shard | 54 (laksa) |
| Root Hash | 7104038400628677254 |
| Unparsed URL | com,git-scm!/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git s443 |