diff --git a/book/08-customizing-git/1-customizing-git.asc b/book/08-customizing-git/1-customizing-git.asc index 7d4efedf..50a831b1 100644 --- a/book/08-customizing-git/1-customizing-git.asc +++ b/book/08-customizing-git/1-customizing-git.asc @@ -1,4 +1,4 @@ -[[_customizing_git]] +[[_customizing_git]] == Personalización de Git Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la @@ -7,7 +7,7 @@ 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á facil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo +será fácil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo necesitéis. include::sections/config.asc[] diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 4917fe8a..340de862 100755 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -1,12 +1,12 @@ -=== Git Attributes +=== Git Attributes (((attributes))) Algunos de los ajustes que hemos visto, pueden ser especificados para un -camino (path) concreto, de tal forma que Git los aplicará unicamente para +camino (path) concreto, de tal forma que Git los aplicará únicamente para una carpeta o para un grupo de archivos determinado. Estos ajustes específicos relacionados con un camino, se denominan atributos en Git. Y se pueden fijar, bien mediante un archivo `.gitattribute` en uno de los directorios de tu -proyecto (normalmente en la raiz del proyecto), o bien mediante el archivo +proyecto (normalmente en la raíz del proyecto), o bien mediante el archivo `git/info/attributes` en el caso de no querer guardar el archivo de atributos dentro de tu proyecto. @@ -14,7 +14,7 @@ Por medio de los atributos, puedes hacer cosas tales como indicar diferentes estrategias de fusión para archivos o carpetas concretas de tu proyecto, decirle a Git cómo comparar archivos no textuales, o indicar a Git que filtre ciertos contenidos antes de guardarlos o de extraerlos del repositorio Git. -En esta sección, aprenderas acerca de algunos atributos que puedes asignar +En esta sección, aprenderás acerca de algunos atributos que puedes asignar a ciertos caminos (paths) dentro de tu proyecto Git, viendo algunos ejemplos de cómo utilizar sus funcionalidades de manera práctica. @@ -23,12 +23,12 @@ de cómo utilizar sus funcionalidades de manera práctica. (((binary files))) Un buen truco donde utilizar los atributos Git es para indicarle cuáles de los archivos son binarios (en los casos en que Git no podría llegar a determinarlo -por sí mismo), dándole a Git instruciones especiales sobre cómo tratar estos +por sí mismo), dándole a Git instrucciones especiales sobre cómo tratar estos archivos. Por ejemplo, algunos archivos de texto se generan automáticamente y no tiene sentido compararlos; mientras que algunos archivos binarios sí que pueden ser comparados. Vamos a ver cómo indicar a Git cuál es cuál. -===== Indentificación de archivos binarios +===== Identificación de archivos binarios Algunos archivos aparentan ser textuales, pero a efectos prácticos merece más la pena tratarlos como binarios. Por ejemplo, los proyectos Xcode en un Mac @@ -89,7 +89,7 @@ mejor utilizando los atributos Git. Poniendo lo siguiente en tu archivo ---- Así decimos a Git que sobre cualquier archivo coincidente con el patrón -indicado, (.docx), ha de utilizar el filtro ``word'' cuando intentente hacer +indicado, (.docx), ha de utilizar el filtro ``word'' cuando intente hacer una comparación con él. ¿Qué es el filtro ``word''? Tienes que configurarlo tú mismo. Por ejemplo, puedes configurar Git para que utilice el programa `docx2txt` para convertir los documentos Word en archivos de texto planos, @@ -148,8 +148,8 @@ mostrará) pero sirve en la mayoría de los casos. Otro problema donde puede ser útil esta técnica, es en la comparación de imágenes. Un camino puede ser pasar los archivos JPEG a través de un filtro para extraer su información EXIF (los metadatos que se graban dentro de la -mayoria de formatos gráficos). Si te descargas e instalas el programa -`exiftool`, puedes utilizarlo para convertir tus imagenes a textos +mayoría de formatos gráficos). Si te descargas e instalas el programa +`exiftool`, puedes utilizarlo para convertir tus imágenes a textos (metadatos), de tal forma que diff podrá al menos mostrarte algo útil de cualquier cambio que se produzca: @@ -203,7 +203,7 @@ realizarlo. La primera, es inyectando automáticamente la suma de comprobación SHA-1 de un gran objeto binario (blob) en un campo '$Id$' dentro del archivo. Si -colocas este attributo en un archivo o conjunto de archivos, Git lo sustituirá +colocas este atributo en un archivo o conjunto de archivos, Git lo sustituirá por la suma de comprobación SHA-1 la próxima vez que lo/s extraiga/s. Es importante destacar que no se trata de la suma SHA de la confirmación de cambios (commit), sino del propio objeto binario (blob): @@ -320,7 +320,7 @@ $ echo 'date*.txt filter=dater' >> .gitattributes ---- Al confirmar cambios (commit) y luego extraer (checkout) el archivo de vuelta, -verás la clave sutituida: +verás la clave sustituida: [source,console] ---- @@ -337,7 +337,7 @@ aplicaciones personalizadas. No obstante, debes de ser cuidadoso, ya que el archivo `.gitattibutes` se almacena y se transmite junto con el proyecto; pero no así el propio filtro, (en este caso, `dater`), sin el cual no puede funcionar. Cuando diseñes este tipo de filtros, han de estar pensados para -que el proyecto continue funcionando correctamente incluso cuando fallen. +que el proyecto continúe funcionando correctamente incluso cuando fallen. ==== Exportación del repositorio @@ -396,7 +396,7 @@ Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$ (((merging, strategies))) También puedes utilizar los atributos Git para indicar distintas estrategias -de fusión para archivos específicos de tu proyecto. Una opción muy util es +de fusión para archivos específicos de tu proyecto. Una opción muy útil es la que nos permite indicar a Git que no intente fusionar ciertos archivos concretos cuando tengan conflictos, manteniendo en su lugar tus archivos sobre los de cualquier otro. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 7a584e79..881465a6 100755 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -1,4 +1,4 @@ -[[_git_config]] +[[_git_config]] === Configuración de Git (((git commands, config))) @@ -17,7 +17,7 @@ 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 estandar, Git emplea +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 @@ -47,10 +47,10 @@ comando `git config`. ==== Configuración básica del cliente Las opciones de configuración reconocidas por Git pueden distribuirse en dos -grandes categorias: las del lado cliente y las del lado servidor. La mayoria +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 comunmente utilizadas o las que afectan +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 @@ -235,7 +235,7 @@ con el fin de que puedas abortar la operación auto-corregida con la opción (((color))) Git puede marcar con colores los resultados que muestra en tu terminal, -ayudandote así a leerlos más facilmente. Hay unos cuantos parámetros que te +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` @@ -309,7 +309,7 @@ tus comandos. En estos ejemplos, voy 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 correspodientes argumentos: +los correspondientes argumentos: [source,console] ---- @@ -319,7 +319,7 @@ $ cat /usr/local/bin/extMerge ---- El script para el comparador, ha de asegurarse de recibir siete argumentos -y de pasar dos de ellos al script de fusion (merge). Por defecto, Git pasa los +y de pasar dos de ellos al script de fusión (merge). Por defecto, Git pasa los siguientes argumentos al programa diff (comparador): [source] @@ -455,7 +455,7 @@ $ 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 estandar diff para +de conflictos de integración y la herramienta estándar diff para las comparaciones. ==== Formateo y espacios en blanco @@ -464,7 +464,7 @@ las comparaciones. 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 facil que algunos parches u otro trabajo +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 @@ -479,7 +479,7 @@ 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 -caracter de salto-de-linea. Esta es una sutil, pero molesta, diferencia +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 @@ -506,7 +506,7 @@ parámetro `core.autocrlf`: $ git config --global core.autocrlf input ---- -Este ajuste dejará los finales de línea CRLF en las extraciones de código +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. @@ -522,7 +522,7 @@ $ git config --global core.autocrlf false ===== `core.whitespace` Git viene preajustado para detectar y resolver algunos de los problemas -más tipicos relacionados con los espacios en blanco. Puede vigilar +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. @@ -540,7 +540,7 @@ 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 dejandolos fuera de la cadena de ajustes, como +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: @@ -585,14 +585,14 @@ 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 envio (push), aunque Git tiene +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 envios, puedes forzarle a hacerlo ajustando +los objetos en todos los envíos, puedes forzarle a hacerlo ajustando a 'true' el parámetro `receive.fsckObjects`: [source,console] @@ -609,12 +609,12 @@ 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 pretendias realizarla. Habitualmente, este +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 envio, +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 envios forzados de referencias de avance no +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`: @@ -625,7 +625,7 @@ $ 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 refencias +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` diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 4abe86b5..91e0c340 100755 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -1,9 +1,9 @@ -[[_git_hooks]] +[[_git_hooks]] === Puntos de enganche en Git (((hooks))) Al igual que en otros sistemas de control de versiones, Git también cuenta -con mecanismos para lanzar scrips de usuario cuando suceden ciertas acciones +con mecanismos para lanzar scripts de usuario cuando suceden ciertas acciones importantes, llamados puntos de enganche (hooks). Hay dos grupos de esos puntos de lanzamiento: los del lado cliente y los del lado servidor. Los puntos del lado cliente están relacionados @@ -56,10 +56,10 @@ Primero se activa el punto de enganche `pre-commit`, incluso antes de que teclees el mensaje de confirmación. Se suele utilizar para inspeccionar la instantánea (snapshot) que vas a confirmar, para ver si has olvidado algo, para asegurar que las pruebas se ejecutan, o para revisar cualquier -aspecto que necesites inspeccionar en el codigo. Saliendo con un valor +aspecto que necesites inspeccionar en el código. Saliendo con un valor de retorno distinto de cero, se aborta la confirmación de cambios. Aunque -siempre puedes saltartelo con la orden `git commit --no-verify`. Puede ser -util para realizar tareas tales como revisar el estilo del código +siempre puedes saltártelo con la orden `git commit --no-verify`. Puede ser +útil para realizar tareas tales como revisar el estilo del código (lanzando `lint` o algo equivalente), revisar los espacios en blanco de relleno (el script de ejemplo hace exactamente eso), o revisar si todos los nuevos métodos llevan la adecuada documentación. @@ -74,8 +74,8 @@ clave SHA-1 si estamos enmendando un commit existente. Este punto de enganche no tiene mucha utilidad para las confirmaciones de cambios normales; pero sí para las confirmaciones donde el mensaje por defecto es autogenerado, como en las confirmaciones de fusiones (merge), los mensajes con plantilla, las -confirmaciones aplastadas (squash), o las confirmaciones de correccion -(amend). Se puede utilizar combinandolo con una plantilla de confirmación, +confirmaciones aplastadas (squash), o las confirmaciones de corrección +(amend). Se puede utilizar combinándolo con una plantilla de confirmación, para poder insertar información automáticamente. El punto de enganche `commit-msg` recibe un parámetro: la ubicación @@ -87,9 +87,9 @@ la última parte de este capítulo, veremos cómo podemos utilizar este punto de enganche para revisar si el mensaje de confirmación es conforme a un determinado patrón obligatorio. -Despues de completar todo el proceso de confirmación de cambios, es cuando +Después de completar todo el proceso de confirmación de cambios, es cuando se lanza el punto de enganche `post-commit`. Este no recibe ningún parámetro, -pero podemos obtener facilmente la última confirmación de cambios con el +pero podemos obtener fácilmente la última confirmación de cambios con el comando `git log -1 HEAD`. Habitualmente, este script final se suele utilizar para realizar notificaciones o tareas similares. @@ -114,7 +114,7 @@ El siguiente punto de enganche que se activa al aplicar parches con `git am` es el punto `pre-applypatch`. No recibe ningún argumento de entrada y se lanza después de que el parche haya sido aplicado, por lo que puedes utilizarlo para revisar la situación (snapshot) antes de confirmarla. Con este script, puedes -lanzar pruebas o similares para chequear el arbol de trabajo. Si falta algo o +lanzar pruebas o similares para chequear el árbol de trabajo. Si falta algo o si alguna de las pruebas falla, saliendo con un código de salida distinto de cero abortará el comando `git am` sin confirmar el parche. @@ -173,15 +173,15 @@ operación, o para poderla abortar si se considera que no es un buen momento. Aparte de los puntos del lado cliente, como administrador de sistemas, puedes utilizar un par de puntos de enganche importantes en el lado servidor; para implementar prácticamente cualquier tipo de política que quieras mantener en tu -proyecto. Estos scripts se lanzan antes y después de cada envio (push) al +proyecto. Estos scripts se lanzan antes y después de cada envío (push) al servidor. El script previo, puede terminar con un código de salida distinto de -cero y abortar el envio, devolviendo el correspondiente mensaje de error al +cero y abortar el envío, devolviendo el correspondiente mensaje de error al cliente. Este script puede implementar políticas de recepción tan complejas como desees. ===== `pre-receive` -El primer script que se activa al manejar un envio de un cliente es el +El primer script que se activa al manejar un envío de un cliente es el correspondiente al punto de enganche `pre-receive`. Recibe una lista de referencias que se están enviando (push) desde la entrada estándar (stdin); y, si termina con un código de salida distinto de cero, ninguna de ellas será @@ -214,6 +214,6 @@ la de alimentar una lista de correo-e, avisar a un servidor de integración continua, o actualizar un sistema de seguimiento de tickets de servicio (pudiendo incluso procesar el mensaje de confirmación para ver si hemos de abrir, modificar o dar por cerrado algún ticket). Este script no puede detener -el proceso de envio, pero el cliente no se desconecta hasta que no se completa +el proceso de envío, pero el cliente no se desconecta hasta que no se completa su ejecución; por tanto, has de ser cuidadoso cuando intentes realizar con él tareas que puedan requerir mucho tiempo. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 8e9fe50a..b303a78a 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -1,13 +1,13 @@ -[[_an_example_git_enforced_policy]] +[[_an_example_git_enforced_policy]] === Un ejemplo de implantación de una determinada política en Git (((policy example))) En esta sección, utilizarás lo aprendido para establecer un flujo de trabajo en Git que: compruebe si los mensajes de confirmación de cambios encajan en un -determinado formato, obligue a realizar solo envios de avance directo, y +determinado formato, obligue a realizar solo envíos de avance directo, y permita solo a ciertos usuarios modificar ciertas carpetas del proyecto. Para ello, has de preparar los correspondientes scripts de cliente (para ayudar a -los desarrolladores a saber de antemano si sus envios van a ser rechazados o +los desarrolladores a saber de antemano si sus envíos van a ser rechazados o no), y los correspondientes scripts de servidor (para obligar a cumplir esas políticas). @@ -28,11 +28,11 @@ y tiene tres argumentos: * La vieja revisión de la rama que se está modificando * La nueva revisión que se está subiendo a la rama -También puedes tener acceso al usuario que está enviando, si este los envia a +También puedes tener acceso al usuario que está enviando, si este los envía a través de SSH. Si has permitido a cualquiera conectarse con un mismo usuario (como "git", por ejemplo), has tenido que dar a dicho usuario una envoltura (shell wraper) que te permite determinar cuál es el usuario que se conecta -según sea su clave pública, permitiendote fijar una variable de entorno +según sea su clave pública, permitiéndote fijar una variable de entorno especificando dicho usuario. Aquí, asumiremos que el usuario conectado queda reflejado en la variable de entorno `$USER`, de tal forma que el script `update` comienza recogiendo toda la información que necesitas: @@ -220,7 +220,7 @@ modificadas por las confirmaciones de cambios enviadas; de tal forma que puedas asegurarte de que el usuario que las está enviando tiene realmente permiso para modificarlas. -Puedes comprobar facilmente qué archivos han sido modificados en cada +Puedes comprobar fácilmente qué archivos han sido modificados en cada confirmación de cambios, utilizando la opción `--name-only` del comando `git log` (citado brevemente en el capítulo 2): @@ -370,7 +370,7 @@ proyecto o en un proyecto separado. Pero no hay modo de implementarlos automáticamente. Para empezar, se necesita chequear el mensaje de confirmación inmediatamente -antes de cada confirmación de cambios, para segurarse de que el servidor no +antes de cada confirmación de cambios, para asegurarse de que el servidor no los rechazará debido a un mensaje mal formateado. Para ello, se añade el enganche `commit-msg`. Comparando el mensaje del archivo pasado como primer argumento con el mensaje patrón, puedes obligar a Git a abortar la confirmación @@ -499,7 +499,7 @@ estar tratando de enviar una rama local distinta sobre la misma rama remota. De todas formas, el único aspecto accidental que puede interesante capturar son los intentos de reorganizar confirmaciones de cambios ya enviadas. El servidor te avisará de que no puedes enviar ningún no-avance-rapido, y el -enganche te impedirá cualquier envio forzado +enganche te impedirá cualquier envío forzado Este es un ejemplo de script previo a reorganización que lo puede comprobar. Con la lista de confirmaciones de cambio que estás a punto de reescribir, las @@ -547,7 +547,7 @@ decir, confirmaciones de avance-rápido. La mayor pega de este sistema es el que puede llegar a ser muy lento; y muchas veces es innecesario, ya que el propio servidor te va a avisar y te impedirá -el envio, siempre y cuando no intentes forzar dicho envio con la opción '-f'. -De todas formas, es un ejercicio interesante. Y, en teoria al menos, pude -ayudarte a evitar reorganizaciones que luego tengas de echar para atras y +el envío, siempre y cuando no intentes forzar dicho envío con la opción '-f'. +De todas formas, es un ejercicio interesante. Y, en teoría al menos, pude +ayudarte a evitar reorganizaciones que luego tengas de echar para atrás y arreglarlas. diff --git a/book/10-git-internals/1-git-internals.asc b/book/10-git-internals/1-git-internals.asc index 19209c04..e735a132 100644 --- a/book/10-git-internals/1-git-internals.asc +++ b/book/10-git-internals/1-git-internals.asc @@ -1,8 +1,8 @@ -[[_git_internals]] +[[_git_internals]] == Los entresijos internos de Git Puede que hayas llegado a este capítulo saltando desde alguno previo o puede que hayas llegado tras leer todo el resto del libro - en uno u otro caso, aquí es donde aprenderás acerca del funcionamiento interno y la implementación de Git. -Nos parece que esta información es realmente importante para entender cúan util y potente es Git, pero algunas personas opinan que puede ser confuso e innecesariamente complejo para novatos. +Nos parece que esta información es realmente importante para entender cuan útil y potente es Git, pero algunas personas opinan que puede ser confuso e innecesariamente complejo para novatos. Por ello, lo hemos puesto en el capítulo final del libro; de tal forma que puedas leerlo antes o después, en cualquier momento, a lo largo de tu proceso de aprendizaje. Lo dejamos en tus manos. @@ -13,7 +13,7 @@ En breve lo veremos con más detalle. En los primeros tiempos de Git (principalmente antes de la versión 1.5), el interface de usuario era mucho más complejo, ya que se centraba en el sistema de archivos en lugar de en el VCS. En los últimos años, el IU se ha refinado hasta llegar a ser tan limpio y sencillo de usar como el de cualquier otro sistema; pero frecuentemente, el estereotipo sigue mostrando a Git como complejo y difícil de aprender. -La capa del sistema de archivos que almacena el contenido es increiblemente interesante; por ello, es lo primero que vamos a desarrollar en este capítulo. +La capa del sistema de archivos que almacena el contenido es increíblemente interesante; por ello, es lo primero que vamos a desarrollar en este capítulo. A continuación mostraremos los mecanismos de transporte y las tareas de mantenimiento del repositorio que posiblemente necesites usar alguna vez. @@ -35,7 +35,7 @@ include::sections/environment.asc[] === Recapitulación -A estas alturas deberias tener una idea bastante clara de como trabaja Git entre bastidores y, hasta cierto punto, sobre cómo está implementado. +A estas alturas deberías tener una idea bastante clara de como trabaja Git entre bastidores y, hasta cierto punto, sobre cómo está implementado. En este capítulo se han visto unos cuantos comandos "de fontanería" -comandos de menor nivel y más simples que los "de porcelana" que hemos estado viendo en el resto del libro. Entendiendo cómo trabaja Git a bajo nivel, es más sencillo comprender por qué hace lo que hace, a la par que facilita la escritura de tus propias herramientas y scripts auxiliares para implementar flujos de trabajo tal y como necesites. diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index d1a7300f..0375b22a 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -1,4 +1,4 @@ -=== Variables de entorno +=== Variables de entorno Git siempre se ejecuta dentro de un shell `bash`, y utiliza una serie de variables de entorno de shell para determinar cómo comportarse. En ocasiones, es muy útil saber cuáles son, y cómo pueden ser utilizadas para hacer que Git se comporte de la manera que deseas. diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 566410c9..09b878d9 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -1,4 +1,4 @@ -=== Mantenimiento y recuperación de datos +=== Mantenimiento y recuperación de datos De vez en cuando, es posible que necesites hacer algo de limpieza, (compactar un repositorio, adecuar un repositorio importado, recuperar trabajo perdido,...). En ese apartado vamos a ver algunos de esos escenarios. @@ -62,7 +62,7 @@ En algún momento de tu trabajo con Git, perderás por error una confirmación d Normalmente, esto suele suceder porque has forzado el borrado de una rama con trabajos no confirmados en ella, y luego te has dado cuenta de que realmente necesitabas dicha rama; o porque has reculado (hard-reset) una rama, abandonando todas sus confirmaciones de cambio, y luego te has dado cuenta que necesitabas alguna de ellas. Asumiendo que estas cosas pasan, ¿cómo podrías recuperar tus confirmaciones de cambio perdidas? -Vamos a ver un ejemplo de un retroceso a una confirmación (commit) antigua en la rama principal de tu repositorio de pruebas, y cómo podriamos recuperar las confirmaciones perdidas en este caso. +Vamos a ver un ejemplo de un retroceso a una confirmación (commit) antigua en la rama principal de tu repositorio de pruebas, y cómo podríamos recuperar las confirmaciones perdidas en este caso. Lo primero es revisar el estado de tu repositorio en ese momento: [source,console] @@ -153,8 +153,8 @@ $ git branch -D recover-branch $ rm -Rf .git/logs/ ---- -La información de registro (reflog) se guarda en la carpeta `.git/logs/`; por lo que, borrandola, nos quedamos efectivamente sin registro. -¿Cómo podriamos ahora recuperar esas confirmaciones de cambio? +La información de registro (reflog) se guarda en la carpeta `.git/logs/`; por lo que, borrándola, nos quedamos efectivamente sin registro. +¿Cómo podríamos ahora recuperar esas confirmaciones de cambio? Una forma es utilizando el comando de chequeo de integridad de la base de datos: `git fsck`. Si lo lanzas con la opción `--full`, te mostrará todos los objetos sin referencias a ningún otro objeto: @@ -175,21 +175,21 @@ Y la puedes recuperar del mismo modo, añadiendo una rama que apunte a esa clave [[_removing_objects]] ==== Borrando objetos -Git tiene grandes cosas, pero el hecho de que un `git clone` siempre descarge la historia completa del proyecto (incluyendo todas y cada una de las versiones de todos y cada uno de los archivos) puede casusar problemas. +Git tiene grandes cosas, pero el hecho de que un `git clone` siempre descargue la historia completa del proyecto (incluyendo todas y cada una de las versiones de todos y cada uno de los archivos) puede causar problemas. Todo suele ir bien si el contenido es únicamente código fuente, ya que Git está tremendamente optimizado para comprimir eficientemente ese tipo de datos. Pero, si alguien, en cualquier momento de tu proyecto, ha añadido un solo archivo enorme, a partir de ese momento, todos los clones, siempre, se verán obligados a copiar ese enorme archivo, incluso si ya ha sido borrado del proyecto en la siguiente confirmación de cambios realizada inmediatamente tras la que lo añadió. Porque en algún momento formó parte del proyecto, siempre permanecerá ahí. Esto suele dar bastantes problemas cuando estás convirtiendo repositorios de Subversion o de Perforce a Git. En esos sistemas, uno no se suele descargar la historia completa y, por tanto, los archivos enormes no tienen mayores consecuencias. -Si, tras una importación de otro sistema, o por otras razones, descubres que tu repositorio es mucho mayor de lo que deberia ser, es momento de buscar y borrar objetos enormes en él. +Si, tras una importación de otro sistema, o por otras razones, descubres que tu repositorio es mucho mayor de lo que debería ser, es momento de buscar y borrar objetos enormes en él. *Una advertencia importante: estas técnicas son destructivas y alteran el historial de confirmaciones de cambio.* Se basan en reescribir todos los objetos confirmados desde el árbol más reciente modificado para borrar la referencia a un archivo enorme. No tendrás problemas si lo haces inmediatamente después de una importación, o justo antes de que alguien haya comenzado a trabajar con la confirmación de cambios modificada --pero si no es el caso, tendrás que avisar a todas las personas que hayan contribuido para que reorganicen su trabajo en base a tus nuevas confirmaciones de cambio--. -Para probarlo por tí mismo, puedes añadir un archivo enorme a tu repositorio de pruebas y retirarlo en la siguiente confirmación de cambios; así podrás practicar la busqueda y borrado permanente del repositorio. -Para emprezar, añade un objeto enorme a tu historial: +Para probarlo por ti mismo, puedes añadir un archivo enorme a tu repositorio de pruebas y retirarlo en la siguiente confirmación de cambios; así podrás practicar la búsqueda y borrado permanente del repositorio. +Para empezar, añade un objeto enorme a tu historial: [source,console] ---- @@ -243,7 +243,7 @@ size-garbage: 0 El valor de `size-pack` nos da el tamaño de tus archivos empaquetadores, en kilobytes, y, por lo que se ve, estás usando casi 5MB. Antes de la última confirmación de cambios, estabas usando algo así como 2KB --resulta claro que esa última confirmación de cambios no ha borrado el archivo enorme del historial--. -A partir de este momento, cada vez que alguien haga un clón de este repositorio, se verá obligado a copiar 5MB para un proyecto tan simple, y todo porque tu añadiste accidentalmente un archivo enorme en algún momento. +A partir de este momento, cada vez que alguien haga un clon de este repositorio, se verá obligado a copiar 5MB para un proyecto tan simple, y todo porque tu añadiste accidentalmente un archivo enorme en algún momento. Deshagámonos de él. Lo primero es localizarlo. @@ -301,11 +301,11 @@ Con eso conseguimos aumentar la velocidad, ya que el proceso es mucho más rápi Aunque también puedes hacer lo mismo con la opción`--tree-filter`, si así lo prefieres. La opción `--ignore-unmatch` indica a `git rm` que evite lanzar errores en caso de no encontrar el patrón que le has ordenado buscar. Y por último, se indica a `filter-branch` que reescriba la historia a partir de la confirmación de cambios `7b30847`, porque ya conocemos que es a partir de ahí donde comenzaba el problema. -De otro modo, el comando comenzaria desde el principio, asumiendo un proceso inecesariamente más largo. +De otro modo, el comando comenzaría desde el principio, asumiendo un proceso innecesariamente más largo. Tras esto, el historial ya no contiene ninguna referencia a ese archivo. Pero, sin embargo, quedan referencias en el registro (reflog) y en el nuevo conjunto de referencias en `.git/refs/original` que Git ha añadido al procesar `filter-branch`, por lo que has de borrar también éstas y reempaquetar la base de datos. -Antes de reempaquetar, asegurate de acabar completamente con cualquier elemento que apunte a las viejas confirmaciones de cambios: +Antes de reempaquetar, asegúrate de acabar completamente con cualquier elemento que apunte a las viejas confirmaciones de cambios: [source,console] ---- diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index a7a89f1a..ecfa321d 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -1,4 +1,4 @@ -[[_objects]] +[[_objects]] === Los objetos Git Git es un sistema de archivo orientado a contenidos. @@ -8,7 +8,7 @@ Pues significa que el núcleo Git es un simple almacén de claves y valores. Cuando insertas cualquier tipo de contenido, él te devuelve una clave que puedes utilizar para recuperar de nuevo dicho contenido en cualquier momento. Para verlo en acción, puedes utilizar el comando de fontanería 'hash-object'. Este comando coge ciertos datos, los guarda en la carpeta '.git.' y te devuelve la clave bajo la cual se han guardado. -Para empezar, inicializa un nuevo repositorio Git y comprueba que la carpeta 'objects' está vacia. +Para empezar, inicializa un nuevo repositorio Git y comprueba que la carpeta 'objects' está vacía. [source,console] ---- @@ -33,7 +33,7 @@ d670460b4b4aece5915caf5c68d12f560a9fe3e4 ---- La opción `-w` indica a `hash-object` que ha de guardar el objeto; de otro modo, el comando solo te respondería cual sería su clave. -La opción `--stdin` indica al comando de leer desde la entrada estandar stdin; si no lo indicas, `hash-object` espera una ruta de archivo al final. +La opción `--stdin` indica al comando de leer desde la entrada estándar stdin; si no lo indicas, `hash-object` espera una ruta de archivo al final. La salida del comando es una suma de comprobación (checksum hash) de 40 caracteres. Este checksum hash SHA-1 es una suma de comprobación del contenido que estás guardando más una cabecera; cabecera sobre la que trataremos en breve. En estos momentos, ya puedes comprobar la forma en que Git ha guardado tus datos: @@ -51,7 +51,7 @@ La subcarpeta se nombra con los primeros 2 caracteres del SHA-1, y el archivo co Puedes volver a recuperar los contenidos usando el comando `cat-file`. Este comando es algo así como una "navaja suiza" para inspeccionar objetos Git. -Pasandole la opción `-p`, puedes indicar al comando `cat-file` que deduzca el tipo de contenido y te lo muestre adecuadamente: +Pasándole la opción `-p`, puedes indicar al comando `cat-file` que deduzca el tipo de contenido y te lo muestre adecuadamente: [source,console] @@ -72,7 +72,7 @@ $ git hash-object -w test.txt 83baae61804e65cc73a7201a7252750c76066a30 ---- -A continuación, escribe algo más de contenido en el archivo y vuelvelo a guardar: +A continuación, escribe algo más de contenido en el archivo y vuélvelo a guardar: [source,console] ---- @@ -124,8 +124,8 @@ blob El siguiente tipo de objeto a revisar serán los árboles, que se encargan de resolver el problema de guardar un nombre de archivo, a la par que guardamos conjuntamente un grupo de archivos. Git guarda contenido de manera similar a un sistema de archivos UNIX, pero de forma algo más simple. -Todo el contenido se guarda como objetos arbol (tree) u objetos binarios (blob), correspondiendo los árboles a las entradas de carpetas; y correspondiendo los binarios, mas o menos, a los contenidos de los archivos (inodes). -Un objeto tipo árbol tiene una o más entradas de tipo arbol, cada una de las cuales consta de un puntero SHA-1 a un objeto binario (blob) o a un subárbol, más sus correspondientes datos de modo, tipo y nombre de archivo. +Todo el contenido se guarda como objetos árbol (tree) u objetos binarios (blob), correspondiendo los árboles a las entradas de carpetas; y correspondiendo los binarios, mas o menos, a los contenidos de los archivos (inodes). +Un objeto tipo árbol tiene una o más entradas de tipo árbol, cada una de las cuales consta de un puntero SHA-1 a un objeto binario (blob) o a un subárbol, más sus correspondientes datos de modo, tipo y nombre de archivo. Por ejemplo, el árbol más reciente en un proyecto puede ser algo como esto: @@ -154,7 +154,7 @@ image::images/data-model-1.png[Versión simplificada del modelo de datos de Git. Puedes crear fácilmente tu propio árbol. Habitualmente Git suele crear un árbol a partir del estado de tu área de preparación (staging area) o índice, escribiendo un serie de objetos árbol desde él. Por tanto, para crear un objeto árbol, previamente has de crear un índice preparando algunos archivos para ser almacenados. -Puedes utilizar el comando de "fontaneria" `update-index` para crear un índice con una sola entrada, --la primera version de tu archivo text.txt--. +Puedes utilizar el comando de "fontanería" `update-index` para crear un índice con una sola entrada, --la primera versión de tu archivo text.txt--. Este comando se utiliza para añadir artificialmente la versión anterior del archivo test.txt a una nueva área de preparación. Has de utilizar la opción `--add`, porque el archivo no existe aún en tu área de preparación (es más, ni siquiera tienes un área de preparación), y has de utilizar también la opción `--cacheinfo`, porque el archivo que estás añadiendo no está en tu carpeta, sino en tu base de datos. Para terminar, has de indicar el modo, la clave SHA-1 y el nombre de archivo: @@ -166,10 +166,10 @@ $ git update-index --add --cacheinfo 100644 \ ---- En este caso, indicas un modo `100644`, el modo que denota un archivo normal. -Otras opciones son `100755`, para un achivo ejecutable; o `120000`, para un enlace simbólico. +Otras opciones son `100755`, para un archivo ejecutable; o `120000`, para un enlace simbólico. Estos modos son como los modos de UNIX, pero mucho menos flexibles -- solo estos tres modos son válidos para archivos (blobs) en Git; (aunque también se permiten otros modos para carpetas y submódulos) --. -Tras esto, puedes usar el comando `write-tree` para escribir el área de preparacón a un objeto tipo árbol. +Tras esto, puedes usar el comando `write-tree` para escribir el área de preparación a un objeto tipo árbol. Sin necesidad de la opción `-w`, solo llamando al comando `write-tree`, y si dicho árbol no existiera ya, se crea automáticamente un objeto tipo árbol a partir del estado del índice. [source,console] @@ -270,7 +270,7 @@ $ echo 'third commit' | git commit-tree 3c4e9c -p cac0cab 1a410efbd13591db07496601ebc7a059dd55cfe9 ---- -Cada uno de estos tres objetos de confirmación de cambios apunta a uno de los tres objetos tipo árbol que habias creado previamente. +Cada uno de estos tres objetos de confirmación de cambios apunta a uno de los tres objetos tipo árbol que habías creado previamente. Más aún, en estos momentos tienes ya un verdadero historial Git, que puedes comprobar con el comando `git log`, lanzándolo mientras estás en la última de las confirmaciones de cambio. [source,console] @@ -335,7 +335,7 @@ image::images/data-model-3.png[Todos los objetos en tu carpeta Git.] ==== Almacenamiento de los objetos Hemos citado anteriormente que siempre se almacena una cabecera junto al contenido. -Vamos a hechar un vistazo a cómo Git almacena sus objetos. +Vamos a echar un vistazo a cómo Git almacena sus objetos. Veamos el proceso de guardar un objeto binario grande (blob), --en este caso la cadena de texto "what is up, doc?" (¿qué hay de nuevo, viejo?)--, interactivamente, en el lenguaje de script Ruby. Puedes arrancar el modo interactivo de Ruby con el comando `irb`: diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 10dac69b..0159e581 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -1,4 +1,4 @@ -=== Archivos empaquetadores +=== Archivos empaquetadores Volviendo a los objetos en la base de datos de tu repositorio Git de pruebas. En este momento, tienes 11 objetos --4 binarios, 3 árboles, 3 confirmaciones de cambios y 1 etiqueta--. @@ -21,7 +21,7 @@ $ find .git/objects -type f Git comprime todos esos archivos con zlib, por lo que ocupan más bien poco, entre todos suponen solamente 925 bytes. Puedes añadir algún otro archivo de gran contenido al repositorio y verás una interesante funcionalidad de Git. -Para demostrarlo, añadiremos el archivo `repo.rb` de la libreria Grit --es un archivo de código fuente de unos 22K--:. +Para demostrarlo, añadiremos el archivo `repo.rb` de la librería Grit --es un archivo de código fuente de unos 22K--:. [source,console] ---- @@ -73,7 +73,7 @@ $ git cat-file -p master^{tree} 100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt ---- -El objeto binario es ahora un binario completamente diferente. Aunque solo has añadido una única línea al final de un archivo que ya contenia 400 líneas, Git ha almacenado el resultado como un objeto completamente nuevo. +El objeto binario es ahora un binario completamente diferente. Aunque solo has añadido una única línea al final de un archivo que ya contenía 400 líneas, Git ha almacenado el resultado como un objeto completamente nuevo. [source,console] ---- @@ -88,7 +88,7 @@ Pues bien, Git lo puede hacer. El formato inicial como Git guarda sus objetos en disco es el formato conocido como "relajado" (loose). Pero, sin embargo, de vez en cuando, Git suele agrupar varios de esos objetos en un único binario denominado archivo "empaquetador", para ahorrar espacio y hacer así más eficiente su almacenamiento. Esto sucede cada vez que tiene demasiados objetos en formato "relajado"; o cuando tu invocas manualmente al comando `git gc`; o justo antes de enviar cualquier cosa a un servidor remoto. -Puedes comprobar el proceso pidiendole expresamente a Git que empaquete objetos, utilizando el comando `git gc`: +Puedes comprobar el proceso pidiéndole expresamente a Git que empaquete objetos, utilizando el comando `git gc`: [source,console] ---- @@ -100,7 +100,7 @@ Writing objects: 100% (18/18), done. Total 18 (delta 3), reused 0 (delta 0) ---- -Tras esto, si miras los objetos presentes en la carpeta, veras que han desaparecido la mayoria de los que habia anteriormente y han apareciendo un par de objetos nuevos: +Tras esto, si miras los objetos presentes en la carpeta, veras que han desaparecido la mayoría de los que había anteriormente y han apareciendo un par de objetos nuevos: [source,console] ---- @@ -117,14 +117,14 @@ Porque nunca los has llegado a incluir en ninguna confirmación de cambios, no s Los otros archivos presentes son el nuevo archivo empaquetador y un índice. El archivo empaquetador es un único archivo conteniendo dentro de él todos los objetos sueltos eliminados del sistema de archivo. -El índice es un archivo que contiene las posiciones de cada uno de esos objetos dentro del archivo empaquetador, permitiendonos así buscarlos y extraer rápidamente cualquiera de ellos. +El índice es un archivo que contiene las posiciones de cada uno de esos objetos dentro del archivo empaquetador, permitiéndonos así buscarlos y extraer rápidamente cualquiera de ellos. Lo que es interesante es el hecho de que, aunque los objetos originales presentes en el disco antes del `gc` ocupaban unos 22 Kbytes, el nuevo archivo empaquetador apenas ocupa 7 Kbytes. Empaquetando los objetos, has conseguido reducir a ⅔ el uso de disco. ¿Cómo consigue Git esto? Cuando Git empaqueta objetos, va buscando archivos de igual nombre y tamaño similar, almacenando únicamente las diferencias entre una versión de cada archivo y la siguiente. Puedes comprobarlo mirando en el interior del archivo empaquetador. -Y, para eso, has de utilizar el comando "de fontaneria" `git verify-pack`: +Y, para eso, has de utilizar el comando "de fontanería" `git verify-pack`: [source,console] ---- @@ -160,5 +160,5 @@ La tercera columna refleja el tamaño de cada objeto dentro del paquete, observ Resulta curioso que se almacene completa la segunda versión del archivo, mientras que la versión original es donde se almacena solo la diferencia --esto se debe a la mayor probabilidad de que vayamos a recuperar rápidamente la versión mas reciente del archivo--. Lo verdaderamente interesante de todo este proceso es que podemos reempaquetar en cualquier momento. -De vez en cuando, Git, en su empeño por optimizar la ocupación de espacio, reempaqueta automaticamente toda la base de datos, pero también tu mismo puedes reempaquetar en cualquier momento, lanzando manualmente el comando `git gc`. +De vez en cuando, Git, en su empeño por optimizar la ocupación de espacio, reempaqueta automáticamente toda la base de datos, pero también tu mismo puedes reempaquetar en cualquier momento, lanzando manualmente el comando `git gc`. diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index 04d2150e..7262a2f3 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -1,4 +1,4 @@ -[[_plumbing_porcelain]] +[[_plumbing_porcelain]] === Fontanería y porcelana Este libro habla acerca de como utilizar Git con más o menos 30 verbos, tales como `checkout`, `branch`, `remote`, etc. @@ -6,7 +6,7 @@ Pero, debido al origen de Git como una caja de herramientas para un VCS en lugar Estos comandos son conocidos como los "comandos de fontanería", mientras que los comandos más amigables son conocidos como los "comandos de porcelana". Los primeros nueve capítulos de este libro se encargan casi exclusivamente de los comandos de porcelana. -Pero en este capítulo trataremos sobre todo con los comandos de fontaneria; comandos que te darán acceso a los entresijos internos de Git y que te ayudarán a comprender cómo y por qué hace Git lo que hace como lo hace. +Pero en este capítulo trataremos sobre todo con los comandos de fontanería; comandos que te darán acceso a los entresijos internos de Git y que te ayudarán a comprender cómo y por qué hace Git lo que hace como lo hace. Muchos de estos comando no están pensados para ser utilizados manualmente desde la línea de comandos; sino más bien para ser utilizados como bloques de construcción para nuevas herramientas y scripts de usuario personalizados. Cuando lanzas `git init` sobre una carpeta nueva o sobre una ya existente, Git crea la carpeta auxiliar `.git`; la carpeta donde se ubica prácticamente todo lo almacenado y manipulado por Git. @@ -28,11 +28,11 @@ refs/ Puede que veas algunos otros archivos en tu carpeta `.git`, pero este es el contenido de un repositorio recién creado tras ejecutar `git init`, -es la estructura por defecto. El archivo `description` se utiliza solo en el programa GitWeb; por lo que no necesitas preocuparte por él. -El archivo `config` contiene las opciones de configuración específicas de este proyecto concreto, y la carpeta `info` guarda un archivo global de exclusión con los patrones a ignorar ademas de los presentes en el archivo `.gitignore`. +El archivo `config` contiene las opciones de configuración específicas de este proyecto concreto, y la carpeta `info` guarda un archivo global de exclusión con los patrones a ignorar además de los presentes en el archivo `.gitignore`. La carpeta `hooks` contiene tus scripts, tanto de la parte cliente como de la parte servidor, tal y como se ha visto a detalle en el <<_git_hooks>>. Esto nos deja con cuatro entradas importantes: los archivos `HEAD` e `index` (todavía por ser creado), y las carpetas `objects` y `refs`. Estos elementos forman el núcleo de Git. -La carpeta `objects` guarda el contenido de tu base de datos, la carpeta `refs` guarda los apuntadores a las confirmaciones de cambios (commits), el archivo `HEAD` apunta a la rama que tengas activa (checked out) en este momento, y el archivo `index` es donde Git almacena la información sobre tu area de preparación (staging area). +La carpeta `objects` guarda el contenido de tu base de datos, la carpeta `refs` guarda los apuntadores a las confirmaciones de cambios (commits), el archivo `HEAD` apunta a la rama que tengas activa (checked out) en este momento, y el archivo `index` es donde Git almacena la información sobre tu área de preparación (staging área). Vamos a mirar en detalle cada una de esas secciones, para ver cómo trabaja Git. diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index 3c78c809..773061db 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -1,7 +1,7 @@ -[[_git_refs]] +[[_git_refs]] === Referencias Git -Puedes utilizar algo así como `git log 1a410e` para echar un vistazo a lo largo de toda tu historia, recorriendola y encontrando todos tus objetos. Pero para ello has necesitado recordar que la última confirmación de cambios es `1a410e`. +Puedes utilizar algo así como `git log 1a410e` para echar un vistazo a lo largo de toda tu historia, recorriéndola y encontrando todos tus objetos. Pero para ello has necesitado recordar que la última confirmación de cambios es `1a410e`. Necesitarías un archivo donde almacenar los valores de las sumas de comprobación SHA-1, junto con sus respectivos nombres simples que puedas utilizar como enlaces en lugar de la propia suma de comprobación. En Git, esto es lo que se conoce como "referencias" o "refs"; en la carpeta `.git/refs` puedes encontrar esos archivos con valores SHA-1 y nombres . @@ -123,7 +123,7 @@ fatal: Refusing to point HEAD outside of refs/ Acabamos de conocer los tres principales tipos de objetos Git, pero hay un cuarto. El objeto tipo etiqueta es muy parecido al tipo confirmación de cambios, --contiene un marcador, una fecha, un mensaje y un enlace--. Su principal diferencia reside en que generalmente apunta a una confirmación de cambios (commit) en lugar de a un árbol (tree). -Es como una referencia a una rama, pero permaneciendo siempre inmóvil, --apuntando siempre a la misma confirmación de cambios--, dándo un nombre mas amigable a esta. +Es como una referencia a una rama, pero permaneciendo siempre inmóvil, --apuntando siempre a la misma confirmación de cambios--, dando un nombre mas amigable a esta. Tal y como se ha comentado en <<_git_basics_chapter>>, hay dos tipos de etiquetas: las anotativas y las ligeras. Puedes crear una etiqueta ligera lanzando un comando tal como: diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index 0a6ea3ed..2b5aca75 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -1,4 +1,4 @@ -[[_refspec]] +[[_refspec]] === Las especificaciones para hacer referencia a... (refspec) A lo largo del libro hemos utilizado sencillos mapeados entre ramas remotas y referencias locales, pero las cosas pueden ser bastante más complejas. @@ -9,7 +9,7 @@ Supón que añades un remoto tal que: $ git remote add origin https://github.com/schacon/simplegit-progit ---- -Esto añade una nueva sección a tu archivo `.git/config`, indicando el nombre del remoto (`origin`), la ubicación (URL) del repositorio remoto y la referencia para recuperar (fench) desde él: +Esto añade una nueva sección a tu archivo `.git/config`, indicando el nombre del remoto (`origin`), la ubicación (URL) del repositorio remoto y la referencia para recuperar (fetch) desde él: [source,ini] ---- @@ -118,7 +118,7 @@ Y, para que se haga de forma automática cada vez que ejecute `git push origin`, push = refs/heads/master:refs/heads/qa/master ---- -Esto hará que un simple comando `git push origin` envie por defecto la rama local `master` a la rama remota `qa/master`, +Esto hará que un simple comando `git push origin` envíe por defecto la rama local `master` a la rama remota `qa/master`, ==== Borrando referencias diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index 1deb5f3d..b45aa746 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -1,4 +1,4 @@ -=== Protocolos de transferencia +=== Protocolos de transferencia Git puede transferir datos entre dos repositorios utilizando uno de sus dos principales mecanismos de transporte: sobre protocolo ''tonto'', o sobre protocolo ''inteligente''. En esta parte, se verán sucintamente cómo trabajan esos dos tipos de protocolo. @@ -6,7 +6,7 @@ En esta parte, se verán sucintamente cómo trabajan esos dos tipos de protocolo ==== El protocolo tonto Si vas a configurar un repositorio para ser servido en forma de sólo lectura a través de HTTP, es probable que uses el protocolo tonto. -Este protocolo se llama ''tonto'' porque no requiere ningún tipo de codigo Git en la parte servidor durante el proceso de transporte; el proceso de recuperación (fetch) de datos se limita a una serie de peticiones GET, siendo el cliente quien ha de conocer la estructura del repositorio Git en el servidor. +Este protocolo se llama ''tonto'' porque no requiere ningún tipo de código Git en la parte servidor durante el proceso de transporte; el proceso de recuperación (fetch) de datos se limita a una serie de peticiones GET, siendo el cliente quien ha de conocer la estructura del repositorio Git en el servidor. [NOTE] ==== @@ -92,7 +92,7 @@ Git comprueba primero a ver si en el listado hay alguna alternativa: ---- En el caso de que esto devolviera una lista de ubicaciones (URL) alternativas, Git busca en ellas (es un mecanismo muy adecuado en aquellos proyectos donde hay segmentos derivados uno de otro compartiendo objetos en disco.) -Pero, en este caso, no hay altenativas, por lo que el objeto debe encontrarse dentro de un empaquetado. +Pero, en este caso, no hay alternativas, por lo que el objeto debe encontrarse dentro de un empaquetado. Para ver que empaquetados hay disponibles en el servidor, has de recuperar el archivo `objects/info/packs`, que contiene una lista de todos ellos: (que ha sido generada por `update-server-info`) [source] @@ -102,7 +102,7 @@ P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack ---- Vemos que hay un archivo empaquetado, y el objeto buscado ha de encontrarse dentro de él; pero merece comprobarlo revisando el archivo de índice, para asegurarse. -Hacer la comprobacion es sobre todo util en aquellos casos donde existan multiples archivos empaquetados en el servidor, para determinar así en cual de ellos se encuentra el objeto que necesitas: +Hacer la comprobación es sobre todo útil en aquellos casos donde existan múltiples archivos empaquetados en el servidor, para determinar así en cual de ellos se encuentra el objeto que necesitas: [source] ---- @@ -155,11 +155,11 @@ El comando `git-receive-pack` responde con una linea por cada una de las referen La primera línea también tiene una lista de las capacidades del servidor (en este caso, `report-status`, `delete-refs`, y algunas otras, incluyendo el identificador del cliente). Cada línea comienza con 4 caracteres, con valor en hexadecimal, indicando la longitud del resto de la línea. -La primera de las líneas comienza con 005b, valor hexadecimal de 91, indicandonos que hay 91 bytes más en esa línea. +La primera de las líneas comienza con 005b, valor hexadecimal de 91, indicándonos que hay 91 bytes más en esa línea. La siguiente línea comienza con 003e, 62 en decimal, por lo que has de leer otros 62 bytes hasta el final de la línea. Y la última línea comienza con 0000, indicando así que la lista de referencias ha terminado. -Con esta información, el proceso `send-pack` ya puede determnar las confirmaciones de cambios (commits) no presentes en el servidor. +Con esta información, el proceso `send-pack` ya puede determinar las confirmaciones de cambios (commits) no presentes en el servidor. Para cada una de las referencias que se van a actualizar, el proceso `send-pack` llama al proceso `receive-pack` con la información pertinente. Por ejemplo, si estás actualizando la rama `master` y añadiendo otra rama `experiment`, la respuesta del proceso `send-pack` será algo así como: diff --git a/book/A-git-in-other-environments/1-git-other-environments.asc b/book/A-git-in-other-environments/1-git-other-environments.asc index d9c647af..a1e464e3 100644 --- a/book/A-git-in-other-environments/1-git-other-environments.asc +++ b/book/A-git-in-other-environments/1-git-other-environments.asc @@ -1,4 +1,4 @@ -[appendix] +[appendix] == Git en otros entornos Si has leído hasta aquí todo el libro, seguro que has aprendido un montón de cosas sobre el uso de Git con la línea de comandos. @@ -26,7 +26,7 @@ include::sections/powershell.asc[] === Resumen -Has aprendido a sarcar partido a toda la potencia de Git desde dentro de la herramienta para poder usarlo en el tu trabajo diario así como a acceder a los repositorios Git desde tus propios programas. +Has aprendido a sacar partido a toda la potencia de Git desde dentro de la herramienta para poder usarlo en el tu trabajo diario así como a acceder a los repositorios Git desde tus propios programas. //// You've learned how to harness Git's power from inside the tools that you use during your everyday work, and also how to access Git repositories from your own programs. //// diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 3c81c7f8..b4a01c62 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -1,4 +1,4 @@ -=== Interfaces gráficas +=== Interfaces gráficas (((GUIs)))(((Graphical tools))) //// @@ -16,8 +16,8 @@ When viewed in this light, none of these tools can be called ``better'' than any Also note that there's nothing these graphical clients can do that the command-line client can't; the command-line is still where you'll have the most power and control when working with your repositories. //// Conviene advertir que los diferentes interfaces están adaptados para diferentes flujos de trabajo. -Algunos clientes sólo disponen de un subconjunto adecuadamente seleccionado de toda la funiconalidad de Git para poder atender una forma contreta de trabajar que los autores consideran eficiente. -Bajo esta perspectiva, ninguna de estas herramientas puede considerase ``mejor'' que otras, simplmente se ajusta mejor a un objetivo prefijado. +Algunos clientes sólo disponen de un subconjunto adecuadamente seleccionado de toda la funcionalidad de Git para poder atender una forma concreta de trabajar que los autores consideran eficiente. +Bajo esta perspectiva, ninguna de estas herramientas puede considerase ``mejor'' que otras, simplemente se ajusta mejor a un objetivo prefijado. Además, no hay nada en estos clientes gráficos que no se encuentre ya en el cliente en línea de comandos y, por tanto, la línea de comandos es el modo con el que se consigue la máxima potencia y control cuando se trabaja con repositorios. ==== `gitk` y `git-gui` @@ -48,7 +48,7 @@ Just `cd` into a Git repository, and type: $ gitk [git log options] ---- -Gitk admite muchas opciones desde la línea de comandos, la mayoria de las cuales se pasan desde la acción `git log` subyacente. +Gitk admite muchas opciones desde la línea de comandos, la mayoría de las cuales se pasan desde la acción `git log` subyacente. Probablemente una de las más útiles sea la opción `--all` que indica a gitk que muestre todos los commit accesibles desde _cualquier_ referencia, no sólo desde el HEAD. La interfaz de gitk tiene este aspecto: //// @@ -114,7 +114,7 @@ You can also choose to amend the last commit by choosing the ``Amend'' radio but Then you can simply stage or unstage some changes, alter the commit message, and click ``Commit'' again to replace the old commit with a new one. //// -`gitk` y `git-gui` son ejmeplos de herramientas orientadas a tareas. +`gitk` y `git-gui` son ejemplos de herramientas orientadas a tareas. Cada una de ellas está adaptada para un propósito específico (visualización del histórico y creación de commits, respectivamente), omitiendo aquellas características que no son necesarias para su tarea. //// `gitk` and `git-gui` are examples of task-oriented tools. @@ -147,7 +147,7 @@ They are designed to look and work very much alike, so we'll treat them like a s We won't be doing a detailed rundown of these tools (they have their own documentation), but a quick tour of the ``changes'' view (which is where you'll spend most of your time) is in order. //// -* A la izquierda se encuentra la lista de repositorios que el cliente tiene en seguimiento. Se pueden añadir un repositorio (bien por clonación o agregándlo localmente) pulsado en el icono ``+'' que está en la parte superor de este área. +* A la izquierda se encuentra la lista de repositorios que el cliente tiene en seguimiento. Se pueden añadir un repositorio (bien por clonación o agregándolo localmente) pulsado en el icono ``+'' que está en la parte superior de este área. * En el centro está el área de entrada de commit, en la que puedes introducir el mensaje del commit y seleccionar los archivos que se tienen que incluir. (En Windows, se visualiza el histórico de commit directamente debajo mientras que en Mac, lo hace en una pestaña separada.) * En la parte derecha está el visor de diferencias que muestra los cambios producidos en el directorio de trabajo o los cambios que se incluyeron en el commit seleccionado. * Por último, se debe tener en cuenta que el botón ``Sync'', en la parte superior derecha, es el principal método de interactuar con la red. @@ -206,7 +206,7 @@ We cover this in more detail in <<_github_flow>>, but the general gist is that ( //// La gestión de ramas es uno de los puntos en donde las dos herramientas varían. -En MAc, hay un botón en la parte superior de la ventana para crear una rama nueva: +En Mac, hay un botón en la parte superior de la ventana para crear una rama nueva: //// Branch management is one of the areas where the two tools diverge. On Mac, there's a button at the top of the window for creating a new branch: @@ -232,7 +232,7 @@ Make some changes in your working directory, and when you switch to the GitHub c Enter a commit message, select the files you'd like to include, and click the ``Commit'' button (ctrl-enter or ⌘-enter). //// -La principal forma de interacturar con otros repositorios en la red es mediante la funcionalidad ``Sync''. +La principal forma de interactuar con otros repositorios en la red es mediante la funcionalidad ``Sync''. Internamente Git dispone de operaciones diferenciadas para mandar (push), recuperar (fetch), fusionar (merge) y reorganizar (rebase), aunque los clientes GitHub juntan todas ellas en una sola funcionalidad multi-paso. Esto es lo que ocurre cuando se pulsa el botón Sync: //// diff --git a/book/B-embedding-git/sections/command-line.asc b/book/B-embedding-git/sections/command-line.asc index 741b1d42..b4eae9c5 100644 --- a/book/B-embedding-git/sections/command-line.asc +++ b/book/B-embedding-git/sections/command-line.asc @@ -1,7 +1,7 @@ -=== Git mediante Línea de Comandos +=== Git mediante Línea de Comandos Una opción es generar un proceso shell y utilizar la herramienta de línea de comandos de Git para hacer el trabajo. -Esto tiene la ventaja de ser canónico, y todas las características de Git estan soportadas. +Esto tiene la ventaja de ser canónico, y todas las características de Git están soportadas. Esto también resulta ser bastante fácil, ya que la mayoría de los entornos de ejecución tienen una forma relativamente sencilla para invocar un proceso con argumentos de la línea de comandos. Sin embargo, este enfoque tiene algunas desventajas. diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index 50b7777e..b3442f71 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -1,4 +1,4 @@ -=== JGit +=== JGit (((jgit)))(((java))) Si deseas utilizar Git desde dentro de un programa Java, hay una biblioteca Git completamente funcional llamada JGit. @@ -98,7 +98,7 @@ ObjectId representa el hash SHA-1 de un objeto, que podría o no existir en la b La tercera línea es similar, pero muestra cómo maneja JGit la sintaxis rev-parse (para más información sobre esto, consulta <<_branch_references>>); puedes pasar cualquier especificador de objeto que Git entienda, y JGit devolverá una ObjectId válida para ese objeto, o `null`. Las dos líneas siguientes muestran cómo cargar el contenido en bruto de un objeto. -En este ejemplo, llamamos a `ObjectLoader.copyTo()` para transmitir el contenido del objeto directamente a la salida estándar, pero ObjectLoader también tiene métodos para leer el tipo y el tamaño de un objeto, así como devoverlo como un array de bytes. +En este ejemplo, llamamos a `ObjectLoader.copyTo()` para transmitir el contenido del objeto directamente a la salida estándar, pero ObjectLoader también tiene métodos para leer el tipo y el tamaño de un objeto, así como devolverlo como un array de bytes. Para objetos grandes (donde `.isLarge()` devuelve true), puedes llamar a `.openStream()` para obtener un objeto similar a InputStream del cual puedes leer los datos del objeto en bruto si almacenarlo en memoria en seguida. Las siguientes líneas muestran lo que se necesita para crear una nueva rama. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 7d2c7761..46b0db18 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -1,4 +1,4 @@ -=== Libgit2 +=== Libgit2 (((libgit2)))(((C))) Otra opción a tu disposición es utilizar Libgit2. @@ -46,7 +46,7 @@ De esta muestra, un par de patrones han comenzado a surgir: * Si se declara un puntero y se pasa una referencia a él en una llamada Libgit2, la llamada devolverá probablemente un código de error entero. Un valor `0` indica éxito; cualquier otra cosa es un error. -* Si Libgit2 rellena un puntero para tí, eres responsable de liberarlo. +* Si Libgit2 rellena un puntero para ti, eres responsable de liberarlo. * Si Libgit2 devuelve un puntero `const` desde una llamada, no tienes que liberarlo, pero no será válido cuando el objeto al que pertenece sea liberado. * Escribir C es un poco doloroso. @@ -112,7 +112,7 @@ Si no eres un rubyista, tocamos algunos otros vínculos en <<_libgit2_bindings>> Libgit2 tiene un par de capacidades que están fuera del ámbito del núcleo de Git. Un ejemplo es la conectividad: Libgit2 te permite proporcionar ''backends'' a medida para varios tipos de operaciones, por lo que puedes almacenar las cosas de una manera diferente a como hace el Git original. -Libgit2 permite backends personalizados para la configuración, el almacenamieno de referencias, y la base de datos de objetos, entre otras cosas. +Libgit2 permite backends personalizados para la configuración, el almacenamiento de referencias, y la base de datos de objetos, entre otras cosas. Echemos un vistazo a cómo funciona esto. El código siguiente se ha tomado del conjunto de ejemplos de backend proporcionados por el equipo de Libgit2 (que se puede encontrar en https://github.com/libgit2/libgit2-backends[]). @@ -234,6 +234,6 @@ pygit2.Repository("/path/to/repo") # open repository ==== Otras Lecturas -Por supuesto, un tratamiento completo de las capacidades de Libgit2 está fuera del alcance de este libro.Si deseas más información sobre Libgit2 en sí mismo, hay documentación de la API en https://libgit2.github.com/libgit2[], y un conjunto de guías en https://libgit2.github.com/docs[]. +Por supuesto, un tratamiento completo de las capacidades de Libgit2 está fuera del alcance de este libro. Si deseas más información sobre Libgit2 en sí mismo, hay documentación de la API en https://libgit2.github.com/libgit2[], y un conjunto de guías en https://libgit2.github.com/docs[]. Para otros vínculos (bindings), comprobar el README incorporado y los tests; a menudo hay pequeños tutoriales y enlaces a otras lecturas allí. diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index e99855bb..f2324f16 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -1,4 +1,4 @@ -[appendix] +[appendix] == Comandos de Git A lo largo del libro hemos introducido docenas de comandos de Git y nos hemos esforzado para introducirlos dentro de una especie de narrativa, añadiendo más comandos a la historia poco a poco. Sin embargo, esto nos deja con ejemplos de uso de los comandos algo dispersos por todo el libro. @@ -300,7 +300,7 @@ Usamos `git archive` para crear un tarball de un proyecto para su compartición ==== git submodule -El comando `git submodule` se utiliza para gestinonar repositorios externos dentro de repositorios normales. +El comando `git submodule` se utiliza para gestionar repositorios externos dentro de repositorios normales. Esto podría ser por bibliotecas u otros tipos de recursos compartidos. El comando `submodule` tiene varios sub-commandos (`add`, `update`, `sync`, etc) para la gestión de estos recursos. Este comando es sólo mencionado y cubierto enteramente en <<_git_submodules>>. @@ -355,7 +355,7 @@ Está cubierto en <<_git_grep>> y sólo se menciona en esa sección. === Parcheo -Unos comandos de Git se centran en el concepto de interpretar los commits en términos de los cambios que introducen, concebiendo las series de commit como series de parches. Estos comandos te ayudan a administrar tus ramas de esta manera. +Unos comandos de Git se centran en el concepto de interpretar los commits en términos de los cambios que introducen, concibiendo las series de commit como series de parches. Estos comandos te ayudan a administrar tus ramas de esta manera. ==== git cherry-pick @@ -377,7 +377,7 @@ También lo usamos en un modo de secuencias de comandos interactiva con la opci ==== git revert -El comando `git revert` es esencialmente un `git cherry-pick` inverso. Crea un nuevo commit que se aplica exactamente al contrario del cambio introducido en el commit que estás apuntando, esencialmente deshaciendo o revertiendolo. +El comando `git revert` es esencialmente un `git cherry-pick` inverso. Crea un nuevo commit que se aplica exactamente al contrario del cambio introducido en el commit que estás apuntando, esencialmente deshaciendo o revertiéndolo. Utilizamos éste en <<_reverse_commit>> para deshacer un commit de fusión. @@ -416,7 +416,7 @@ Examinamos un ejemplo de contribución a un proyecto mediante el envío de parch ==== git request-pull -El comando `git request-pull` se utiliza simplemente para generar un cuerpo de mensaje de ejemplo para enviar por correo electrónico a alguien. Si tienes una rama en un servidor público y quieres que alguien sepa cómo integrar esos cambios sin enviar los parches a través de correo electrónico, puedes ejecutar este comando y enviar el resultado a la persona que deseas que rebiba los cambios. +El comando `git request-pull` se utiliza simplemente para generar un cuerpo de mensaje de ejemplo para enviar por correo electrónico a alguien. Si tienes una rama en un servidor público y quieres que alguien sepa cómo integrar esos cambios sin enviar los parches a través de correo electrónico, puedes ejecutar este comando y enviar el resultado a la persona que deseas que reviva (pull) los cambios. Mostramos como usar `git request-pull` para generar un mensaje pull en <<_public_project>>. diff --git a/book/introduction.asc b/book/introduction.asc index 1304e607..de225e1e 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -13,7 +13,7 @@ Si el libro arde espontáneamente en este punto, ya deberías estar lo suficient El *Capítulo 3* trata sobre el modelo de ramificación (branching) en Git, a menudo descrito como la característica asesina de Git. Aquí aprenderás lo que realmente diferencia Git del resto. -Cuando hayas terminado, puedes sentir la necesidad de pasar un momento tranquilo ponderando cómo has vivido antes de que la ramificación de Git formara parte de tu vida. +Cuando hayas terminado, puedes sentir la necesidad de pasar un momento tranquilo ponderando cómo has vivido antes de que la ramificación de Git formará parte de tu vida. El *Capítulo 4* cubrirá Git en el servidor. Este capítulo es para aquellos que deseen configurar Git dentro de su organización o en su propio servidor personal para la colaboración.