diff --git a/A-git-in-other-environments.asc b/A-git-in-other-environments.asc index 8b83c52f..9d9035c6 100644 --- a/A-git-in-other-environments.asc +++ b/A-git-in-other-environments.asc @@ -1,10 +1,11 @@ -[#A-git-in-other-environments] [appendix] +[#A-git-in-other-environments] == 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. Se puede trabajar con archivos locales, conectar nuestro repositorio con otros repositorios en la red y realizar nuestro trabajo eficientemente con ellos. Aunque las opciones no terminan ahí, Git se utiliza con parte de un ecosistema mayor y un terminal no siempre es la mejor forma de trabajar. Vamos a ver otros tipos de entornos en los que Git resulta muy útil y cómo otras aplicaciones (incluidas las tuyas) pueden trabajar conjuntamente con Git. + //// If you read through the whole book, you've learned a lot about how to use Git at the command line. You can work with local files, connect your repository to others over a network, and work effectively with others. diff --git a/B-embedding-git.asc b/B-embedding-git.asc index 5e9b8a23..82a0a5ee 100644 --- a/B-embedding-git.asc +++ b/B-embedding-git.asc @@ -2,7 +2,7 @@ [appendix] == Integrando Git en tus Aplicaciones -Si tu aplicación es para desarrolladores, es muy probable que pueda beneficiarse de la integración con el control de código fuente. +Si tu aplicación es para desarrolladores, es muy probable que pueda beneficiarse de la integración con el control de código fuente. Incluso las aplicaciones que no sean para desarrolladores, tales como editores de documentos, podrían beneficiarse de las características de control de versiones, y el modelo de Git funciona muy bien para muchos escenarios diferentes. Si necesitas integrar Git con tu aplicación, tienes básicamente tres opciones: generar un shell y usar la herramienta de línea de comandos de Git; Libgit2; y JGit. diff --git a/C-git-commands.asc b/C-git-commands.asc index 2c68c255..ce1bd9fe 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -1,12 +1,11 @@ [#C-git-commands] -[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. +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. En este apéndice, repasaremos todos los comandos de Git que hemos tratado a lo largo del libro, agrupados por el uso que se les ha dado. Vamos a hablar de lo que hace cada comando de manera muy general y a continuación señalaremos en qué parte del libro puedes encontrar un uso de él. - === Configuración Hay dos comandos que se usan bastante, desde las primeras invocaciones de Git hasta el ajuste y referenciamiento diario, los comandos `config` y `help`. @@ -64,7 +63,7 @@ En <> nos fijamos en el uso de la opción ` En <> lo usamos para desempaquetar un repositorio Git empaquetado (bundle). -Finalmente, en <> aprendemos la opción `--recursive` para realizar la clonación de un repositorio con submódulos un poco más simple. +Finalmente, en <> aprendemos la opción `--recursive` para realizar la clonación de un repositorio con submódulos un poco más simple. Aunque se usa en muchos otros lugares a través del libro, estos son los que son algo únicos o donde se utiliza en formas que son un poco diferentes. @@ -111,7 +110,7 @@ Finalmente, lo usamos para realmente comparar cambios en submódulos con `--subm El comando `git difftool` simplemente lanza una herramienta externa para mostrar la diferencia entre dos árboles, en caso de que desees utilizar algo que no sea el comando`git diff` incorporado. -Mencionamos sólo brevemente esto en <<_git_diff_staged >>. +Mencionamos sólo brevemente esto en <>. ==== git commit @@ -139,9 +138,9 @@ Utilizamos `git reset --hard` para abortar una fusión en <>, incluyendo la eliminación de archivos de forma recursiva y sólo la eliminación de archivos desde el área de ensayo, pero dejándolos en el directorio de trabajo con `--cached`. +Cubrimos el comando `git rm` con cierto detalle en <>, incluyendo la eliminación de archivos de forma recursiva y sólo la eliminación de archivos desde el área de ensayo, pero dejándolos en el directorio de trabajo con `--cached`. El único otro uso diferente de `git rm` en el libro está en <>, donde utilizamos brevemente y explicamos el `--ignore-unmatch` al ejecutar `git filter-branch`, el cual simplemente hace que no salga un error cuando el archivo que estamos tratando de eliminar no existe. Esto puede ser útil para fines de scripting. @@ -192,7 +191,7 @@ La herramienta `git merge` se utiliza para fusionar uno o más ramas dentro de l El comando `git merge` fue introducido por primera en <>. A pesar de que se utiliza en diversos lugares en el libro, hay muy pocas variaciones del comando `merge` -- en general, sólo `git merge ` con el nombre de la rama individual que se desea combinar. -Cubrimos cómo hacer una fusión aplastada (squashed merge) (donde Git fusiona el trabajo, pero finge como si fuera simplemente un nuevo commit sin registrar la historia de la rama que se está fusionando) al final de <>. +Cubrimos cómo hacer una fusión aplastada (squashed merge) (donde Git fusiona el trabajo, pero finge como si fuera simplemente un nuevo commit sin registrar la historia de la rama que se está fusionando) al final de <>. Repasamos mucho sobre el proceso de fusión y dirección, incluyendo el comando `-Xignore-all-whitespace` y el indicador `--abort` para abortar un problema de fusión en <>. @@ -218,11 +217,11 @@ En <> lo utilizamos con la opción `--de En <> y <> cubrimos la sintaxis `branchA..branchB` al usar el comando `git log` para ver que commits son únicos a una rama en relación a otra rama. En <> repasamos esto bastante extensamente. -En <> y <> cubrimos el uso del formato `branchA...branchB` y la sintaxis `--left-right` para ver que está en una rama o en la otra pero no en ambas. En <> también vemos como utilizar la opción `--merge` para ayudarnos con la depuración de conflictos de fusión así como el uso de la opción `--cc` para ver conflictos de fusión en tu historia. +En <> y <> cubrimos el uso del formato `branchA...branchB` y la sintaxis `--left-right` para ver que está en una rama o en la otra pero no en ambas. En <> también vemos como utilizar la opción `--merge` para ayudarnos con la depuración de conflictos de fusión así como el uso de la opción `--cc` para ver conflictos de fusión en tu historia. En <> usamos la opción `-g` para ver el reflog de Git a través de esta herramienta en lugar de hacer un recorrido de la rama. -En <> vemos el uso de las opciones `-S` y `-L` para hacer búsquedas bastante sofisticados de algo que sucedió históricamente en el código como ver la historia de una función. +En <> vemos el uso de las opciones `-S` y `-L` para hacer búsquedas bastante sofisticados de algo que sucedió históricamente en el código como ver la historia de una función. En <> vemos como usar `--show-signature` para añadir una cadena de texto de validación a cada commit en la salida de `git log` basado en si fue válidadmente firmado o no. @@ -301,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 gestionar 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 <>. @@ -338,7 +337,7 @@ Git tiene un par de comandos que se utilizan para ayudar a depurar un problema e ==== git bisect -La herramienta `git bisect` es una herramienta de depuración increíblemente útil, utilizada para encontrar qué commit específico fue el primero en introducir un bug o problema, haciendo una búsqueda binaria automática. +La herramienta `git bisect` es una herramienta de depuración increíblemente útil, utilizada para encontrar qué commit específico fue el primero en introducir un bug o problema, haciendo una búsqueda binaria automática. Está completamente cubierto de <> y sólo se menciona en esa sección. @@ -366,9 +365,9 @@ Esto se describe y se muestra en <>. ==== git rebase -El comando `git rebase` es básicamente un `cherry-pick` automatizado. Determina una serie de commits y luego los escoge uno a uno en el mismo orden en otro lugar. +El comando `git rebase` es básicamente un `cherry-pick` automatizado. Determina una serie de commits y luego los escoge uno a uno en el mismo orden en otro lugar. -El rebasing se cubre en detalle en <>, inclusive cubriendo las incidencias de colaboración involucradas con el rebasing de ramas que ya son públicas. +El rebasing se cubre en detalle en <>, inclusive cubriendo las incidencias de colaboración involucradas con el rebasing de ramas que ya son públicas. Lo usamos en la práctica durante un ejemplo de dividir la historia en dos repositorios separados en <>, utilizando el indicador `--onto` también. @@ -428,9 +427,9 @@ Git viene con unos pocos comandos para integrarse con otros sistemas de control ==== git svn -El comando `git svn` se utiliza para comunicarnos como cliente con el sistema de control de versiones Subversion. +El comando `git svn` se utiliza para comunicarnos como cliente con el sistema de control de versiones Subversion. -Esto significa que puedes usar Git para obtener desde y enviar a un servidor Subversion. +Esto significa que puedes usar Git para obtener desde y enviar a un servidor Subversion. Este comando es cubierto en profundidad en <>. @@ -469,7 +468,7 @@ También repasamos un ejemplo práctico de la recuperación de tal rama perdida El comando `git filter-branch` se utiliza para reescribir un montón de commits de acuerdo a ciertos patrones, como la eliminación de un archivo de todas partes o el filtrado de todo el repositorio a un solo subdirectorio para sacar un proyecto. -En <> explicamos el comando y exploramos varias opciones diferentes, tales como `--commit-filter`, `--subdirectory-filter` y `--tree-filter`. +En <> explicamos el comando y exploramos varias opciones diferentes, tales como `--commit-filter`, `--subdirectory-filter` y `--tree-filter`. En <> y <> lo usamos para arreglar repositorios externos importados. diff --git a/Gemfile b/Gemfile index c29231e0..e92c7519 100644 --- a/Gemfile +++ b/Gemfile @@ -14,7 +14,7 @@ gem 'asciidoctor-pdf-cjk-kai_gen_gothic', '~> 0.1.1' gem 'coderay' gem 'pygments.rb' gem 'thread_safe' -gem 'epubcheck-ruby' +gem 'epubcheck' gem 'kindlegen' gem 'octokit' diff --git a/Gemfile.lock b/Gemfile.lock index 4a7abcae..ba583fc5 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -52,7 +52,7 @@ GEM concurrent-ruby (1.0.5) css_parser (1.6.0) addressable - epubcheck-ruby (4.0.2.1) + epubcheck (3.0.1) faraday (0.14.0) multipart-post (>= 1.2, < 3) faraday-http-cache (2.0.0) @@ -126,7 +126,7 @@ DEPENDENCIES asciidoctor-pdf-cjk-kai_gen_gothic (~> 0.1.1) awesome_print coderay - epubcheck-ruby + epubcheck github_changelog_generator! json kindlegen diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 1d4d80c7..23f051d4 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -14,7 +14,7 @@ Git no maneja ni almacena sus datos de esta forma. Git maneja sus datos como un .Almacenamiento de datos como instantáneas del proyecto a través del tiempo. image::images/snapshots.png[Git stores data as snapshots of the project over time.] -Esta es una diferencia importante entre Git y prácticamente todos los demás VCS. Hace que Git reconsidere casi todos los aspectos del control de versiones que muchos de los demás sistemas copiaron de la generación anterior. Esto hace que Git se parezca más a un sistema de archivos miniatura con algunas herramientas tremendamente poderosas desarrolladas sobre él, que a un VCS. Exploraremos algunos de los beneficios que obtienes al modelar tus datos de esta manera cuando veamos ramificación (branching) en Git en el (véase <>) (véase el link:../../03-git-branching/1-git-branching.asc[Capítulo 3]). FIXME +Esta es una diferencia importante entre Git y prácticamente todos los demás VCS. Hace que Git reconsidere casi todos los aspectos del control de versiones que muchos de los demás sistemas copiaron de la generación anterior. Esto hace que Git se parezca más a un sistema de archivos miniatura con algunas herramientas tremendamente poderosas desarrolladas sobre él, que a un VCS. Exploraremos algunos de los beneficios que obtienes al modelar tus datos de esta manera cuando veamos ramificación (branching) en Git en el (véase <>). ==== Casi todas las operaciones son locales @@ -41,7 +41,7 @@ Verás estos valores hash por todos lados en Git porque son usados con mucha fre Cuando realizas acciones en Git, casi todas ellas solo añaden información a la base de datos de Git. Es muy difícil conseguir que el sistema haga algo que no se pueda enmendar, o que de algún modo borre información. Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía. Pero después de confirmar una copia instantánea en Git es muy difícil de perderla, especialmente si envías tu base de datos a otro repositorio con regularidad. -Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de estropear gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver <> link:../../02-git-basics/sections/undoing.asc[Capítulo 2]. FIXME +Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de estropear gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver <>. ==== Los Tres Estados @@ -64,4 +64,4 @@ El flujo de trabajo básico en Git es algo así: 2. Preparas los archivos, añadiéndolos a tu área de preparación. 3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación y almacena esa copia instantánea de manera permanente en tu directorio de Git. -Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified). En el <> link:../../02-git-basics[Capítulo 2] aprenderás más acerca de estos estados y de cómo puedes aprovecharlos o saltarte toda la parte de preparación. +Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified). En <> aprenderás más acerca de estos estados y de cómo puedes aprovecharlos o saltarte toda la parte de preparación. diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index d7f25f54..c4086e16 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -12,4 +12,4 @@ En el 2005, la relación entre la comunidad que desarrollaba el kernel de Linux * Completamente distribuido * Capaz de manejar grandes proyectos (como el kernel de Linux) eficientemente (velocidad y tamaño de los datos) -Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales. Es tremendamente rápido, muy eficiente con grandes proyectos, y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <>) (véase el link:../../03-git-branching/1-git-branching.asc[Capítulo 3]). FIXME +Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales. Es tremendamente rápido, muy eficiente con grandes proyectos, y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <>) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index d6acd9bb..c75ef566 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -2,7 +2,7 @@ Antes de empezar a utilizar Git, tienes que instalarlo en tu computadora. Incluso si ya está instalado, este es posiblemente un buen momento para actualizarlo a su última versión. Puedes instalarlo como un paquete, a partir de un archivo instalador, o bajando el código fuente y compilándolo tú mismo. -[NOTA] +[NOTE] ==== Este libro fue escrito utilizando la versión *2.0.0* de Git. Aun cuando la mayoría de comandos que usaremos deben funcionar en versiones más antiguas de Git, es posible que algunos de ellos no funcionen o funcionen ligeramente diferente si estás utilizando una versión anterior de Git. Debido a que Git es particularmente bueno en preservar compatibilidad hacia atrás, cualquier versión posterior a 2.0 debe funcionar bien. ==== diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 0d5a5d49..4f6ac47a 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -15,7 +15,7 @@ Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`. Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin/master`. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar. -[NOTA] +[NOTE] .``origin'' no es especial ==== Así como la rama ``master'' no tiene ningún significado especial en Git, tampoco lo tiene ``origin''. ``master'' es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, ``origin'' es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah/master` como rama remota por defecto.(((origin))) diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index e1414eef..4953c928 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -2,7 +2,7 @@ === Configurando Git en un servidor Ahora vamos a cubrir la creación de un servicio de Git ejecutando estos protocolos en su propio servidor. -[NOTA] +[NOTE] ==== Aquí demostraremos los comandos y pasos necesarios para hacer las instalaciones básicas simplificadas en un servidor basado en Linux, aunque también es posible ejecutar estos servicios en los servidores Mac o Windows. Configurar un servidor de producción dentro de tu infraestructura sin duda supondrá diferencias en las medidas de seguridad o de las herramientas del sistema operativo, pero se espera que esto le de la idea general de lo que el proceso involucra. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 19e8903c..ab63ea6c 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -503,7 +503,7 @@ $ git commit $ git commit ----- -[NOTA] +[NOTE] ==== Puede usar `rebase -i` para reducir su trabajo a una única confirmación, o reorganizar el trabajo en las confirmaciones para que el desarrollador pueda revisar el parche más fácilmente. Consulte << _ rewriting_history >> para obtener más información sobre el rebase interactivo. ==== diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index a4b46c6c..ff46651f 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -9,7 +9,7 @@ En esta sección, veremos cuáles podrían ser algunos de esos problemas y qué ==== Conflictos de Fusión -Si bien cubrimos algunos conceptos básicos para resolver conflictos de fusión en <<_conflictos_de_fusión_básicos>>, para conflictos más complejos, Git proporciona algunas herramientas para ayudarlo a descubrir qué está sucediendo y cómo lidiar mejor con el conflicto. +Si bien cubrimos algunos conceptos básicos para resolver conflictos de fusión en <>, para conflictos más complejos, Git proporciona algunas herramientas para ayudarlo a descubrir qué está sucediendo y cómo lidiar mejor con el conflicto. En primer lugar, si es posible, intente asegurarse de que su directorio de trabajo esté limpio antes de realizar una fusión que pueda tener conflictos. Si tiene un trabajo en progreso, hágale commit a una rama temporal o stash. Esto hace que puedas deshacer *cualquier cosa* que intentes aquí. Si tiene cambios no guardados en su directorio de trabajo cuando intenta fusionarlos, algunos de estos consejos pueden ayudarlo a perder ese trabajo. @@ -26,7 +26,7 @@ end hello() ---- -En nuestro repositorio, creamos una nueva rama llamada `whitespace` y procedemos a cambiar todas las terminaciones de línea de Unix a terminaciones de línea de DOS, esencialmente cambiando cada línea del archivo, pero solo con espacios en blanco. Luego cambiamos la línea ``hello world'' a ``hello mundo''. +En nuestro repositorio, creamos una nueva rama llamada `whitespace` y procedemos a cambiar todas las terminaciones de línea de Unix a terminaciones de línea de DOS, esencialmente cambiando cada línea del archivo, pero solo con espacios en blanco. Luego cambiamos la línea "hello world" a "hello mundo". [source,console] ---- @@ -156,7 +156,7 @@ $ git show :2:hello.rb > hello.ours.rb $ git show :3:hello.rb > hello.theirs.rb ---- -Si quieres ponerte un poco más intenso, también puedes usar el comando de plomería `ls-files -u` para obtener el verdadero SHA-1s de las manchas de Git para cada uno de los archivos. +Si quieres ponerte un poco más intenso, también puedes usar el comando de plomería `ls-files -u` para obtener el verdadero SHA-1s de las manchas de Git para cada uno de los archivos. [source,console] ---- @@ -168,7 +168,7 @@ $ git ls-files -u El `:1:hello.rb` es solo una clave para buscar esa mancha SHA-1. -Ahora que tenemos el contexto de estas tres etapas en nuestro directorio de trabajo, manualmente podemos arreglar los de ellos para solucionar los problemas de espacios en blanco y volver a fusionar el archivo con el poco conocido comando `git merge-file` que hace exactamente eso. +Ahora que tenemos el contexto de estas tres etapas en nuestro directorio de trabajo, manualmente podemos arreglar los de ellos para solucionar los problemas de espacios en blanco y volver a fusionar el archivo con el poco conocido comando `git merge-file` que hace exactamente eso. [source,console] ---- @@ -195,9 +195,9 @@ index 36c06c8,e85207e..0000000 hello() ---- -En este punto, hemos agradablemente fusionado el archivo. De hecho, esto en realidad funciona mejor que la opción de `ignore-all-space` porque esto realmente soluciona los cambios de los espacios en blanco antes de la fusión, en lugar de simplemente ignorarlo. En la fusión `ignore-all-space, realmente, terminamos con unas pocas líneas con finales de línea DOS, haciendo que las cosas se mezclen. +En este punto, hemos agradablemente fusionado el archivo. De hecho, esto en realidad funciona mejor que la opción de `ignore-all-space` porque esto realmente soluciona los cambios de los espacios en blanco antes de la fusión, en lugar de simplemente ignorarlo. En la fusión `ignore-all-space, realmente, terminamos con unas pocas líneas con finales de línea DOS, haciendo que las cosas se mezclen. -Si quieres tener una idea antes de finalizar este compromiso sobre qué había cambiado en realidad entre un lado y el otro, puedes pedirle a `git diff` que compare qué hay en tu directorio de trabajo que estas a punto de comprometer como resultado de la fusión a cualquiera de estas etapas. Vamos a través de todas ellas. +Si quieres tener una idea antes de finalizar este compromiso sobre qué había cambiado en realidad entre un lado y el otro, puedes pedirle a `git diff` que compare qué hay en tu directorio de trabajo que estas a punto de comprometer como resultado de la fusión a cualquiera de estas etapas. Vamos a través de todas ellas. Para comparar el resultado con lo que tenías en tu rama antes de la fusión, en otra palabras, para ver lo que tu fusión insertó, puedes correr `git diff --ours` @@ -263,7 +263,7 @@ index ac51efd..44d0a25 100755 hello() ---- -En este punto podemos usar el comando `git clean` para limpiar los archivos sobrantes que creamos para hacer el manual de la fusión, pero que ya no necesitamos. +En este punto podemos usar el comando `git clean` para limpiar los archivos sobrantes que creamos para hacer el manual de la fusión, pero que ya no necesitamos. [source,console] ---- @@ -276,7 +276,7 @@ Removing hello.theirs.rb [[r_checking_out_conflicts]] ===== Revisando Los Conflictos -Tal vez en este punto no estemos felices con la resolución por alguna razón, o quizás manualmente editando uno o ambos lados todavía no funciona como es debido y necesitamos más contexto. +Tal vez en este punto no estemos felices con la resolución por alguna razón, o quizás manualmente editando uno o ambos lados todavía no funciona como es debido y necesitamos más contexto. Cambiemos el ejemplo un poco. Para este ejemplo, tenemos dos ramas de larga vida las cuales cada una tiene unos pocos cometidos en ellas aparte de crear un contenido de conflicto legítimo cuando es fusionado. @@ -320,11 +320,11 @@ end hello() ---- -Ambos lados de la fusión han añadido contenido a este archivo, pero algunos de los cometidos han modificado el archivo en el mismo lugar que causó el conflicto. +Ambos lados de la fusión han añadido contenido a este archivo, pero algunos de los cometidos han modificado el archivo en el mismo lugar que causó el conflicto. Exploremos un par de herramientas que ahora tienes a tu disposición para determinar cómo el conflicto resultó ser. Tal vez no es tan obvio qué tan exactamente deberías solucionar este problema. Necesitas más contexto. -Una herramienta útil es `git checkout` con la opción ‘--conflicto’. Esto revisará el archivo de nuevo y reemplazará los marcadores de conflicto de la fusión. Esto puede ser útil si quieres reiniciar los marcadores y tratar de resolverlos de nuevo. +Una herramienta útil es `git checkout` con la opción ‘--conflicto’. Esto revisará el archivo de nuevo y reemplazará los marcadores de conflicto de la fusión. Esto puede ser útil si quieres reiniciar los marcadores y tratar de resolverlos de nuevo. Puedes pasar `--conflict` en lugar de `diff3` o `merge` (lo que es por defecto). Si pasas `diff3`, Git usará una versión un poco diferente de marcadores de conflicto, no solo dándote ``ours'' versión y la versión de ``theirs'', sino también la versión ``base'' en línea para darte más contexto. @@ -396,7 +396,7 @@ En su lugar, si corremos eso con la opción `-p` obtienes, solo los diffs del ar ===== Formato Diff Combinado -Dado que las etapas de Git clasifican los resultados que tienen éxito, cuando corres `git diff` mientras está en un estado de conflicto de fusión, solo puedes obtener lo que está actualmente en conflicto. Esto puede ser útil para ver lo que todavía debes resolver. +Dado que las etapas de Git clasifican los resultados que tienen éxito, cuando corres `git diff` mientras está en un estado de conflicto de fusión, solo puedes obtener lo que está actualmente en conflicto. Esto puede ser útil para ver lo que todavía debes resolver. Cuando corres directamente `git diff` después de un conflicto de fusión, te dará la información en un formato de salida diff bastante único. @@ -423,7 +423,7 @@ index 0399cd5,59727f0..0000000 El formato es llamado ``Diff combinado'' y proporciona dos columnas de datos al lado de cada línea. La primera columna muestra si esa línea es diferente (añadido o removido) entre la rama ``nuestra'' y el archivo en tu directorio de trabajo, y la segunda columna hace lo mismo entre la rama “de ellos” y la copia de tu directorio de trabajo. -Así que en ese ejemplo se puede observar que las líneas <<<<<<< y >>>>>>> están en la copia de trabajo, pero no en ningún lado de la fusión. Esto tiene sentido porque la herramienta de fusión las mantiene ahí para nuestro contexto, pero se espera removamos. +Así que en ese ejemplo se puede observar que las líneas <<<<<<< y >>>>>>> están en la copia de trabajo, pero no en ningún lado de la fusión. Esto tiene sentido porque la herramienta de fusión las mantiene ahí para nuestro contexto, pero se espera removamos. Si resolvemos el conflicto y corremos `git diff` de nuevo, veremos la misma cosa, pero es un poco más útil. @@ -447,7 +447,7 @@ index 0399cd5,59727f0..0000000 hello() ---- -Esto muestra que ``hola mundo'' estaba de nuestro lado, pero no en la copia de trabajo, que ``hello mundo'' estaba en el lado de ellos, pero no en la copia de trabajo y finalmente que ``hola mundo'' no estaba en ningún lado, sin embargo está ahora en la copia de trabajo. Esto puede ser útil para revisar antes de comprometer la resolución. +Esto muestra que ``hola mundo'' estaba de nuestro lado, pero no en la copia de trabajo, que ``hello mundo'' estaba en el lado de ellos, pero no en la copia de trabajo y finalmente que ``hola mundo'' no estaba en ningún lado, sin embargo está ahora en la copia de trabajo. Esto puede ser útil para revisar antes de comprometer la resolución. También se puede obtener desde el `git log` para cualquier fusión después del hecho, para ver cómo algo se resolvió luego de este. Git dará salida a este formato si se puede correr `git show` en un compromiso de fusión, o si se añade la opción `--cc` a un `git log -p` (el cual por defecto solo muestras parches para compromisos no fusionados). @@ -483,10 +483,10 @@ index 0399cd5,59727f0..e1d0799 [[r_undoing_merges]] ==== Deshaciendo Fusiones -Ahora que ya conoces como crear un merge commit (compromiso de fusión), probablemente hayas creado algunos por error. +Ahora que ya conoces como crear un merge commit (compromiso de fusión), probablemente hayas creado algunos por error. Una de las ventajas de trabajar con Git es que está bien cometer errores, porque es posible (y en muchos casos es fácil) solucionarlos. -Los compromisos de fusión no son diferentes. +Los compromisos de fusión no son diferentes. Digamos que comenzaste a trabajar en una rama temática accidentalmente fusionada en una rama `master`, y ahora el historial de compromiso se ve así: .Accidental merge commit @@ -496,7 +496,7 @@ Existen dos formas de abordar este problema, dependiendo de cuál es el resultad ===== Solucionar las referencias -Si el compromiso de fusión no deseado solo existe en tu repositorio local, la mejor y más fácil solución es mover las ramas para que así apunten a dónde quieres que lo hagan. +Si el compromiso de fusión no deseado solo existe en tu repositorio local, la mejor y más fácil solución es mover las ramas para que así apunten a dónde quieres que lo hagan. En la mayoría de los casos si sigues al errante `git merge` con `git reset --hard HEAD~`, esto restablecerá los punteros de la rama, así que se verá así: .History after `git reset --hard HEAD~` @@ -505,7 +505,7 @@ image::images/undomerge-reset.png[History after `git reset --hard HEAD~`.] Ya vimos `restablecer` de nuevo en <>, así que no debería ser muy difícil averiguar lo que está sucediendo ahí Aquí un repaso rápido: `reset --hard` usualmente va a través de tres pasos: -. Mover los puntos de la rama HEAD. +. Mover los puntos de la rama HEAD. En este caso, se quiere mover la `principal`a donde se encontraba antes el compromiso de fusión (`C6`). . Hacer que el índice parezca HEAD. . Hacer que el directorio de trabajo parezca el índice. @@ -517,7 +517,7 @@ Este enfoque tampoco funcionará si cual quiera de los otros compromisos han sid [[r_reverse_commit]] ===== Revertir el compromiso -Si mover los punteros de la rama alrededor no funciona para ti, Git te proporciona la opción de hacer un compromiso (commit) nuevo que deshace todos los cambios de uno ya existente. +Si mover los punteros de la rama alrededor no funciona para ti, Git te proporciona la opción de hacer un compromiso (commit) nuevo que deshace todos los cambios de uno ya existente. Git llama a esta operación un ``revertir', y en este escenario en particular, has invocado algo así: [source,console] @@ -535,7 +535,7 @@ El historial con el compromiso revertido se ve así: .History after `git revert -m 1` image::images/undomerge-revert.png[History after `git revert -m 1`.] -El nuevo compromiso `^M` tiene exactamente los mismos contenidos que `C6`, así que comenzando desde aquí es como si la fusión nunca hubiese sucedido, excepto que la ahora los no fusionados compromisos están todavía en `HEAD`'s history. +El nuevo compromiso `^M` tiene exactamente los mismos contenidos que `C6`, así que comenzando desde aquí es como si la fusión nunca hubiese sucedido, excepto que la ahora los no fusionados compromisos están todavía en `HEAD`'s history. Git se confundirá si intentas fusionar la rama `temática` en la rama `master`: [source,console] @@ -563,7 +563,7 @@ $ git merge topic image::images/undomerge-revert3.png[History after re-merging a reverted merge.] En este ejemplo, `M` y `^M` se cancelan. -Efectivamente `^^M` se fusiona en los cambios desde `C3` y `C4`, y `C8` se fusiona en los cambios desde `C7`, así que ahora `topic` está completamente fusionado. +Efectivamente `^^M` se fusiona en los cambios desde `C3` y `C4`, y `C8` se fusiona en los cambios desde `C7`, así que ahora `topic` está completamente fusionado. ==== Otros Tipos de Fusiones @@ -605,7 +605,7 @@ En este caso, en lugar de obtener marcadores de conflicto en el archivo con ``he Esta opción también puede ser trasmitida al comando `git merge-file` que vimos antes al correr algo como esto `git merge-file --ours` para archivos de fusión individuales. -Si quieres realizar algo así, pero Git no ha intentado siquiera fusionar cambios desde el otro lado, hay una opción más draconiana, la cual es la estrategia de fusión ``ours'' merge _strategy. Esto es diferente de la opción de fusión recursiva ``ours'' recursive merge _option_. +Si quieres realizar algo así, pero Git no ha intentado siquiera fusionar cambios desde el otro lado, hay una opción más draconiana, la cual es la estrategia de fusión ``ours'' merge _strategy. Esto es diferente de la opción de fusión recursiva ``ours'' recursive merge _option_. Esto básicamente hace una fusión falsa. Registrará un nuevo compromiso de fusión con ambas ramas como padres, pero ni siquiera mirará a la rama que estas fusionando. Simplemente registrará como el resultado de la fusión el código exacto en tu rama actual. @@ -619,8 +619,8 @@ $ Puedes observar que no hay diferencia entre la rama en la que estábamos y el resultado de la fusión. -Esto a menudo puede ser útil para básicamente engañar a Git para que piense que una rama ya ha sido fusionada cuando se hace una fusión más adelante. Por ejemplo, decir que has ramificado una rama de ``release'' y has hecho un poco de trabajo que querrás fusionar de vuelta en tu rama ``master'' en algún punto. -Mientras tanto, algunos arreglos de fallos en la ``master'' necesitan ser adaptados en la rama de `release`. Se puede fusionar la rama “bugfix” en la de `release` y también `merge -s ours`, la misma rama en la principal (a pesar de que el arreglo ya se encuentre ahí) Así que, más tarde cuando fusiones la de lanzamiento otra vez, no hay conflictos del bugfix. +Esto a menudo puede ser útil para básicamente engañar a Git para que piense que una rama ya ha sido fusionada cuando se hace una fusión más adelante. Por ejemplo, decir que has ramificado una rama de ``release'' y has hecho un poco de trabajo que querrás fusionar de vuelta en tu rama ``master'' en algún punto. +Mientras tanto, algunos arreglos de fallos en la ``master'' necesitan ser adaptados en la rama de `release`. Se puede fusionar la rama “bugfix” en la de `release` y también `merge -s ours`, la misma rama en la principal (a pesar de que el arreglo ya se encuentre ahí) Así que, más tarde cuando fusiones la de lanzamiento otra vez, no hay conflictos del bugfix. include::subtree-merges.asc[] diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index e57f965e..3934a25f 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -3,7 +3,7 @@ (((credentials))) (((git commands, credential))) -Si usa protocolo SSH para conectar a los remotos, es posible tener una llave sin clave, lo que permite +Si usa protocolo SSH para conectar a los remotos, es posible tener una llave sin clave, lo que permite tranferir la data sin tener que escribir el nombre de usuario y la clave cada vez. Sin embargo, esto no es posible por el protocolo HTTP - cada conexión necesita usuario y contraseña. Esto se vuelve incluso más complicado para sistemas con autenticación de dos pasos, donde el token que @@ -55,7 +55,7 @@ Aquí se muestra cómo se vería un archivo `.gitconfig` si tuviera un archivo d helper = cache --timeout 30000 ---- -==== Bajo el sombrero +==== Bajo el sombrero ¿Cómo funciona todo esto? El comando raíz de Git para el asistente de credenciales es `git credential`, el cual toma un comando como argumento, y luego más inputs por medio de stdin. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 5543f79f..d115bc18 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -21,7 +21,7 @@ c6e1e95 fourth commit c1822cf first commit ---- -zQueremos dividir esto en dos líneas de la historia. Una línea pasa de comprometer uno a cometer cuatro - que será el histórico. La segunda línea sólo se compromete cuatro y cinco - que será la historia reciente. +Queremos dividir esto en dos líneas de la historia. Una línea pasa de comprometer uno a cometer cuatro - que será el histórico. La segunda línea sólo se compromete cuatro y cinco - que será la historia reciente. image::images/replace1.png[] @@ -80,7 +80,7 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree} [NOTE] ===== -El comando `commit-tree` es uno de un conjunto de comandos que comúnmente se denominan comandos 'plumbing'. Estos son comandos que no suelen ser utilizados directamente, sino que son utilizados por ** ** ** otros comandos Git para hacer trabajos más pequeños. En ocasiones, cuando estamos haciendo cosas más extrañas como estas, nos permiten hacer cosas de nivel muy bajo, pero no son para uso diario. Puede leer más acerca de los comandos de plomería en << _ plumbing_porcelain >> +El comando `commit-tree` es uno de un conjunto de comandos que comúnmente se denominan comandos 'plumbing'. Estos son comandos que no suelen ser utilizados directamente, sino que son utilizados por ** ** ** otros comandos Git para hacer trabajos más pequeños. En ocasiones, cuando estamos haciendo cosas más extrañas como estas, nos permiten hacer cosas de nivel muy bajo, pero no son para uso diario. Puede leer más acerca de los comandos de plomería en <> ===== image::images/replace3.png[] diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 7b5e159a..b1b976b3 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -30,7 +30,6 @@ En general, es más simple pensar en HEAD como la instantánea de *su última co De hecho, es bastante fácil ver cómo se ve esa instantánea. Aquí hay un ejemplo de cómo obtener la lista del directorio real y las sumas de comprobación SHA-1 para cada archivo en la instantánea de HEAD: -======= [source,console] ---- diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index bd78684a..47e03e21 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -63,7 +63,7 @@ Generalmente, de ocho a diez caracteres son más que suficientes para ser único Como un ejemplo, el kernel Linux, que es un proyecto bastante grande con alrededor de 450 mil commits y 3.6 millones de objetos, no tiene dos objetos cuyos SHA-1s se superpongan antes de los primeros 11 caracteres. [NOTE] -.UNA BREVE NOTA RESPECTO A SHA-1 +.UNA BREVE NOTE RESPECTO A SHA-1 ==== Mucha gente se preocupa de que en cierto momento, fruto del azar, tendrán dos objetos en us repositorio cuyos hash tendrán el mismo valor SHA-1. diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index be8bc70d..fc03274d 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -1,7 +1,7 @@ [[r_rewriting_history]] -Reescribiendo la Historia +=== Reescribiendo la Historia -Muchas veces, al trabajar con Git, vas a querer confirmar tu historia por alguna razón. +Muchas veces, al trabajar con Git, vas a querer confirmar tu historia por alguna razón. Una de las grandes cualidades de Git es que te permite tomar decisiones en el último momento. Puede decidir qué archivos entran en juego antes de comprometerse con el área de ensayo, puedes decidir que no querías estar trabajando en algo todavía con el comando de alijos, y puedes reescribir confirmaciones que ya hayan pasado haciendo parecer que fueron hechos de diferente manera. Esto puede desenvolverse en el cambio de las confirmaciones, cambiando mensajes o modificando los archivos en un cometido, aplastando o dividiendo confirmaciones enteramente – todo antes de que compartas tu trabajo con otras personas. @@ -9,9 +9,9 @@ Esto puede desenvolverse en el cambio de las confirmaciones, cambiando mensajes En esta sección, verás cómo complementar esas tareas tan útiles que harán parece que la confirmación de tu historia parezca del modo en el cual quisiste compartirla. [[r_git_amend]] -==== Cambiando la última confirmación +==== Cambiando la última confirmación -Cambiar la última confirmación es probablemente lo más común que le harás a tu historia. +Cambiar la última confirmación es probablemente lo más común que le harás a tu historia. Comúnmente querrás hacer dos cosas en tu ultima confirmación: cambiar la confirmación del mensaje, o cambiar la parte instantánea que acabas de agregar sumando, cambiando y removiendo archivos. Si solamente quieres cambiar la confirmación del mensaje final, es muy sencillo: @@ -34,7 +34,7 @@ Es como un muy pequeño rebase – no necesitas modificar tu ultima confirmació ==== Cambiando la confirmación de múltiples mensajes Para modificar una confirmación que está más atrás en tu historia, deberás aplicar herramientas más complejas -Git no tiene una herramienta para modificar la historia, pero puedes usar la herramienta de rebase para rebasar ciertas series confirmaciones en el HEAD en el que se basaron originalmente en lugar de moverlos a otro. +Git no tiene una herramienta para modificar la historia, pero puedes usar la herramienta de rebase para rebasar ciertas series confirmaciones en el HEAD en el que se basaron originalmente en lugar de moverlos a otro. Con la herramienta interactiva del rebase, puedes parar justo después de cada confirmación que quieras modificar y cambiar su mensaje, añadir archivos, o hacer cualquier cosa que quieras Puedes ejecutar el rebase interactivamente agregando el `-i` option to `git rebase`. De igual manera debes indicar que tan atrás quieres regresar para reescribir las confirmaciones escribiendo en el comando cual confirmación quieres rebasar. @@ -90,11 +90,11 @@ f7f3f6d changed my name a bit Nótese que el orden esta al revés. El rebase interactivo te da un script que va a utilizarse. -Este empezará en la confirmación que especificas en la línea de comandos (`HEAD~3`) y reproducir los cambios introducidos en cada una de estas confirmaciones de arriba a abajo. +Este empezará en la confirmación que especificas en la línea de comandos (`HEAD~3`) y reproducir los cambios introducidos en cada una de estas confirmaciones de arriba a abajo. Este acomoda los más viejos en la parte de arriba, y va bajando hasta los más nuevos, porque ese será el primero en reproducirse Necesitaras editar el script para que se detenga en la confirmación que quieres editar. -Para hacer eso, cambia la palabra `pick' por la frase `edit' para cada una de las confirmaciones en las que quieres que el script se detenga. +Para hacer eso, cambia la palabra `pick` por la frase `edit` para cada una de las confirmaciones en las que quieres que el script se detenga. Por ejemplo, para modificar solamente la tercera confirmación del mensaje, cambiarias el archivo para que se viera algo así: [source,console] @@ -160,7 +160,7 @@ pick 310154e updated README formatting and added blame pick f7f3f6d changed my name a bit ---- -Cuando guardes y salgas del editor, Git te recordará de tu rama de padres de estas confirmaciones, aplicando 310154e y después f7f3f6d, y después se parará. +Cuando guardes y salgas del editor, Git te recordará de tu rama de padres de estas confirmaciones, aplicando 310154e y después f7f3f6d, y después se parará. Cambias efectivamente el orden de esas confirmaciones y eliminas la “added cat-file’’ confirmación completamente. [[r_squashing]] @@ -189,7 +189,7 @@ El script pone instrucciones que en el mensaje de rebase: # Note that empty commits are commented out ---- -Si, en vez de ``pick'' o``edit'', especificas ``squash'', Git aplica a ambos este cambio y los cambia directamente después y hace que las confirmaciones se unan. +Si, en vez de ```pick'' o```edit'', especificas ``squash'', Git aplica a ambos este cambio y los cambia directamente después y hace que las confirmaciones se unan. Entonces, si quieres convertir en una única confirmación de estas tres confirmaciones, deberás hacer que el script se vea como esto: [source,console] @@ -218,12 +218,12 @@ added cat-file Cuando guardes eso, tendrás una única confirmación que introducirá los cambios de las tres previas confirmaciones. -==== Dividiendo una confirmación +==== Dividiendo una confirmación Dividir una confirmación la deshace y después realiza etapas parcialmente de las confirmaciones tantas veces como confirmaciones desees finalizar. Por ejemplo, suponiendo que quieres dividir la confirmación de en medio de tus tres confirmaciones. -En vez de ``updated README formatting and added blame'', quieres dividirla en dos confirmaciones: ``updated README formatting'' para la primera, y ``added blame''para la segunda. -Puedes hacer eso en el rebase -i` script cambiando la instruccion en la confirmacion que quieres dividir a ``edit'': +En vez de ```updated README formatting and added blame'', quieres dividirla en dos confirmaciones: ``updated README formatting'' para la primera, y ``added blame'' para la segunda. +Puedes hacer eso en el `rebase -i` script cambiando la instruccion en la confirmacion que quieres dividir a ``edit'': [source,console] ---- @@ -232,7 +232,7 @@ edit 310154e updated README formatting and added blame pick a5f4a0d added cat-file ---- -¿Entonces, cuando el script te envié a la línea de comandos, tu reseteas esa confirmación, tomas los cambios que se han hecho, y creas múltiples confirmación fuera de ellas? +¿Entonces, cuando el script te envié a la línea de comandos, tu reseteas esa confirmación, tomas los cambios que se han hecho, y creas múltiples confirmación fuera de ellas? Cuando guardes y salgas del editor, Git te enviará al padre de la primer confirmación en tu lista, Aplica a la primera confirmación (`f7f3f6d`), aplicando a la segunda (`310154e`) y te enviará directamente a la consola. Ahí, puedes hacer un reseteo mixto de esa confirmación con el `git reset HEAD^`, el que efectivamente deshace las confirmaciones en los archivos hasta que tengas. Ahora puedes organizar y confirmar los archivos hasta que tenga varias confirmaciones y ejecutar `git rebase --continuar` cuando haya terminado: @@ -268,12 +268,12 @@ Como sea, podría ser muy útil. Aprenderás unas cuantas maneras muy comunes de obtener una idea de algunas de las cosas que es capaz de hacer. [[r_removing_file_every_commit]] -===== Remover un archivo de cada confirmación +===== Remover un archivo de cada confirmación Esto ocurre comúnmente. Esto ocurre comúnmente. Alguien accidentalmente confirma un gran numero binario de un archivo con un irreflexivo `git add .`, y quieres removerlo de todas partes. Suponiendo que accidentalmente confirmaste un archivo que contenía contraseña y quieres volverlo un proyecto abierto. -`filter-branch` es la herramienta que tu probablemente quieres usar para limpiar toda tu historia. +`filter-branch` es la herramienta que tu probablemente quieres usar para limpiar toda tu historia. Para remover un archivo nombrado passwords.txt de tu historia complete puedes usar el `--tree-filter` option to `filter-branch`: [source,console] @@ -289,12 +289,12 @@ si quieres remover todas las confirmaciones accidentales del respaldo del editor Deberías ser capaz de ver la reescripción de confirmaciones y estructuras del Git y luego debes mover el puntero de la rama al final. Es generalmente una buena idea hacer esto en una parte de prueba de la rama y después hacer un hard-reset de tu rama principal después de haber determinado que el resultado es lo que realmente deseas. -Para iniciar `filter-branch` en todas las ramas, puedes poner `--all` en el comando. +Para iniciar `filter-branch` en todas las ramas, puedes poner `--all` en el comando. ===== Hacer que un subdirectorio sea la nueva raíz Suponiendo que has hecho un importe de otro centro de Sistema de control y tienes subdirecciones que no tienen ningún sentido (tronco, etiquetas, etc). . - Si quieres hacer que el `tronco` subdirectorio sea el nuevo proyecto de la raíz de cada confirmación, `filter-branch`te puede ayudar a hacer eso, también: + Si quieres hacer que el `tronco` subdirectorio sea el nuevo proyecto de la raíz de cada confirmación, `filter-branch`te puede ayudar a hacer eso, también: [source,console] ---- @@ -325,5 +325,5 @@ $ git filter-branch --commit-filter ' fi' HEAD ---- -Esto va a traves de la reescripcion de cada confirmacion para tener tu nuva direccion. +Esto va a traves de la reescripcion de cada confirmacion para tener tu nuva direccion. Por que cada confirmacion contiene el SHA-1 de sus padres, este comando cambia cada confirmacion del SHA-1 en tu historia, no solamente aquellos en los cuales el e-mail es el mismo o encaja. diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 57ae2020..6da85ba6 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -4,9 +4,6 @@ Con casi cualquier tamaño de código de base, a menudo necesitará encontrar en dónde se llama o define una función, o encontrar el historial de un método. Git proporciona un par de herramientas útiles para examinar el código y hacer commit a las almacenadas en su base de datos de forma rápida y fácil. Vamos a revisar algunos de ellos. -======= - - [[r_git_grep]] ==== Git Grep @@ -15,9 +12,6 @@ Git se envía con un comando llamado `grep` que le permite buscar fácilmente a Por defecto, mirará a través de los archivos en su directorio de trabajo. Puede pasar `-n` para imprimir los números de línea donde Git ha encontrado coincidencias. -======= - - [source,console] ---- $ git grep -n gmtime_r @@ -37,9 +31,6 @@ Hay una serie de opciones interesantes que puede proporcionar el comando `grep`. Por ejemplo, en lugar de la llamada anterior, puede hacer que Git resuma el resultado simplemente mostrándole qué archivos coinciden y cuántas coincidencias hay en cada archivo con la opción `--count`: -======= - - [source,console] ---- $ git grep --count gmtime_r @@ -52,9 +43,6 @@ git-compat-util.h:2 Si quiere ver qué método o función piensa que ha encontrado una coincidencia, puede pasar `-p`: -======= - - [source,console] ---- $ git grep -p gmtime_r *.c @@ -70,9 +58,6 @@ También puede buscar combinaciones complejas de cadenas con el indicador `--and Aquí también usaremos las opciones `--break` y `--heading` que ayudan a dividir el resultado en un formato más legible. -======= - - [source,console] ---- $ git grep --break --heading \ @@ -104,9 +89,7 @@ El comando `git grep` tiene algunas ventajas sobre los comandos de búsqueda nor Quizás no está buscando **dónde** existe un término, sino **cuando** existió o se introdujo. El comando `git log` tiene varias herramientas potentes para encontrar commits específicas por el contenido de sus mensajes o incluso el contenido de las diferencias que introducen. -Si queremos saber, por ejemplo, cuándo se introdujo originalmente la constante `ZLIB_BUF_MAX`, podemos decirle a Git que solo nos muestre los commits que agregaron o eliminaron esa cadena con la opción `-S`. - -======= +Si queremos saber, por ejemplo, cuándo se introdujo originalmente la constante `ZLIB_BUF_MAX`, podemos decirle ac Git que solo nos muestre los commits que agregaron o eliminaron esa cadena con la opción `-S`. [source,console] ---- @@ -125,9 +108,6 @@ Otra búsqueda de registro bastante avanzada que es increíblemente útil es la Por ejemplo, si quisiéramos ver cada cambio realizado en la función `git_deflate_bound` en el archivo `zlib.c`, podríamos ejecutar `git log -L :git_deflate_bound:zlib.c`. Esto intentará descubrir cuáles son los límites de esa función y luego examinará el historial y nos mostrará cada cambio que se hizo a la función como una serie de parches de nuevo cuando se creó la función por primera vez. -======= - - [source,console] ---- $ git log -L :git_deflate_bound:zlib.c @@ -167,6 +147,3 @@ diff --git a/zlib.c b/zlib.c ---- Si Git no puede encontrar la forma de relacionar una función o método en su lenguaje de programación, también puede proporcionarle una expresión regular. Por ejemplo, esto habría hecho lo mismo: `git log -L '/unsigned long git_deflate_bound/',/^}/:zlib.c`. También podría darle un rango de líneas o un único número de línea y obtendrá el mismo tipo de salida. - -======= - diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 62c7b22a..2fb535db 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -54,9 +54,8 @@ Changes to be committed: En primer lugar, debe observar el nuevo archivo `.gitmodules`. Este es un archivo de configuración que almacena la asignación entre la URL del proyecto y el subdirectorio local en el que lo ha insertado: -[source,console] +[source,ini] ---- -$ cat .gitmodules [submodule "DbConnector"] path = DbConnector url = https://github.com/chaconinc/DbConnector @@ -67,7 +66,7 @@ Es importante tener en cuenta que este archivo está controlado por la versión Se empuja y hala con el resto de su proyecto. Así es como otras personas que clonan este proyecto saben de dónde obtener los proyectos de submódulos. -[NOTA] +[NOTE] ===== Dado que la URL en el archivo .gitmodules es lo que otras personas intentarán primero clonar/buscar, asegúrese de usar una URL a la que puedan acceder si es posible. Por ejemplo, si usa una URL diferente a la que presionar para que otros la utilicen, utilice aquella a la que otros tienen acceso. Puede sobrescribir este valor localmente con `git config submodule.DbConnector.url PRIVATE_URL` para su propio uso. ===== @@ -312,7 +311,7 @@ index 6fc0b3d..fd1cc29 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,3 +1,4 @@ - [submodule "DbConnector"] +[submodule "DbConnector"] path = DbConnector url = https://github.com/chaconinc/DbConnector + branch = stable @@ -325,8 +324,6 @@ index 6fc0b3d..fd1cc29 100644 Esto es muy bueno ya que podemos ver el registro de las commits a las que estamos a punto de hacer commit en nuestro submódulo. Una vez hecha la commit, puede ver esta información también cuando ejecuta `git log -p`. -======= - [source,console] ---- @@ -366,7 +363,6 @@ Hasta ahora, cuando ejecutamos el comando `git submodule update` para obtener ca Para configurar su submódulo para que sea más fácil entrar y piratear, necesita hacer dos cosas. Necesita ingresar a cada submódulo y verificar una rama para trabajar. Entonces necesita decirle a Git qué hacer si ha hecho cambios y luego `git submodule update --remote` extrae un nuevo trabajo de upstream. Las opciones son que puede combinarlas en su trabajo local, o puede tratar de volver a establecer la base de su trabajo local además de los nuevos cambios. Primero que todo, vamos a nuestro directorio de submódulos y verifiquemos una rama. -======= [source,console] ---- @@ -375,7 +371,7 @@ Switched to branch 'stable' ---- Probemos con la opción ``merge''. Para especificarlo manualmente, solo podemos agregar la opción `--merge` a nuestra llamada `update`. Aquí veremos que hubo un cambio en el servidor para este submódulo y se fusionó. -======= + [source,console] ---- @@ -394,7 +390,7 @@ Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5e ---- Si vamos al directorio de DbConnector, tenemos los nuevos cambios ya fusionados en nuestra rama `stable` local. Ahora veamos qué sucede cuando hacemos nuestro propio cambio local a la biblioteca y alguien más impulsa otro cambio en sentido ascendente al mismo tiempo. -======= + [source,console] ---- @@ -406,7 +402,7 @@ $ git commit -am 'unicode support' ---- Ahora, si actualizamos nuestro submódulo podemos ver qué sucede cuando hemos realizado un cambio local y upstream también tiene un cambio que necesitamos incorporar. -======= + [source,console] ---- @@ -417,7 +413,7 @@ Submodule path 'DbConnector': rebased into '5d60ef9bbebf5a0c1c1050f242ceeb54ad58 ---- Si olvida `--rebase` o `--merge`, Git simplemente actualizará el submódulo a lo que esté en el servidor y restablecerá su proyecto a un estado detached HEAD. -======= + [source,console] ---- @@ -428,7 +424,7 @@ Submodule path 'DbConnector': checked out '5d60ef9bbebf5a0c1c1050f242ceeb54ad58d Si esto sucede, no se preocupe, simplemente puede volver al directorio y verificar su rama nuevamente (que aún contendrá su trabajo) y combinar o rebasar `origin/stable` (o cualquier rama remota que desee) manualmente. Si no ha hecho commit a los cambios en su submódulo y ejecuta una actualización de submódulo que podría causar problemas, Git buscará los cambios pero no sobrescribirá el trabajo no guardado en el directorio de su submódulo. -======= + [source,console] ---- @@ -447,7 +443,7 @@ Unable to checkout 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path ---- Si realizó cambios que entran en conflicto con algo cambiado en upstream, Git le informará cuándo ejecutar la actualización. -======= + [source,console] ---- @@ -460,14 +456,14 @@ Unable to merge 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'Db ---- Puede acceder al directorio de submódulos y solucionar el conflicto tal como lo haría normalmente. -======= + [[r_publishing_submodules]] ===== Publicando Cambios de Submódulo Ahora tenemos algunos cambios en nuestro directorio de submódulos. Algunos de estos fueron enviados desde el inicio por nuestras actualizaciones y otros fueron hechos localmente y todavía no están disponibles para nadie, ya que aún no los hemos promocionado. -======= + [source,console] ---- @@ -483,7 +479,7 @@ Submodule DbConnector c87d55d..82d2ad3: Si hacemos commit en el proyecto principal y lo elevamos sin elevar los cambios del submódulo también, otras personas que intenten verificar nuestros cambios estarán en problemas ya que no tendrán forma de obtener los cambios del submódulo de los que dependen . Esos cambios solo existirán en nuestra copia local. Para asegurarse de que esto no ocurra, puede pedirle a Git que verifique que todos sus submódulos se hayan elevado correctamente antes de empujar el proyecto principal. El comando `git push` toma el argumento `--recurse-submodules` que puede configurarse como ``check'' o ``on-demand''. La opción ``check'' hará que `push` simplemente falle si alguno de los cambios cometidos del submódulo no ha sido elevado. -======= + [source,console] ---- @@ -506,7 +502,7 @@ to push them to a remote. Como puede ver, también nos da algunos consejos útiles sobre lo que podríamos hacer a continuación. La opción simple es ir a cada submódulo y empujar manualmente a los controles remotos para asegurarse de que estén disponibles externamente y luego probar este empuje de nuevo. La otra opción es usar el valor ``on-demand'', que intentará hacer esto por usted. -======= + [source,console] ---- @@ -537,7 +533,7 @@ Si cambia una referencia de submódulo al mismo tiempo que otra persona, puede t Si uno de los commits es un antecesor directo del otro (una fusión de avance rápido), entonces Git simplemente elegirá el último para la fusión, por lo que funciona bien. Sin embargo, Git no intentará siquiera una fusión trivial para ti. Si los commits del submódulo divergen y necesitan fusionarse, obtendrá algo que se ve así: -======= + [source,console] ---- @@ -558,7 +554,6 @@ Automatic merge failed; fix conflicts and then commit the result. Básicamente, lo que sucedió aquí es que Git ha descubierto que las dos ramas registran puntos en la historia del submódulo que son divergentes y necesitan fusionarse. Lo explica como ``merge following commits not found'', lo cual es confuso pero explicaremos el por qué en un momento. Para resolver el problema, debe averiguar en qué estado debería estar el submódulo. Curiosamente, Git no le da demasiada información para ayudar aquí, ni siquiera los SHA-1 de las commits de ambos lados de la historia. Afortunadamente, es fácil de entender. Si ejecuta `git diff`, puede obtener los SHA-1 de las commits registradas en ambas ramas que estaba intentando fusionar. -======= [source,console] ---- diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 42cdaeab..a68ca495 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -238,7 +238,7 @@ puedes determinar si el usuario tiene o no permiso para enviar dichos cambios: [source,ruby] ---- -# only allows certain users to modify certain subdirectories in a project + # only allows certain users to modify certain subdirectories in a project def check_directory_perms access = get_acl_access_data('acl') @@ -423,9 +423,9 @@ previamente, este script `pre-commit` podrá comprobar los límites: $user = ENV['USER'] -# [ insert acl_access_data method from above ] + # [ insert acl_access_data method from above ] -# only allows certain users to modify certain subdirectories in a project + # only allows certain users to modify certain subdirectories in a project def check_directory_perms access = get_acl_access_data('.git/acl') diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index fc2a7c4d..2f683b22 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -314,7 +314,7 @@ Git-p4 es un puente de dos vías entre Git y Perforce. Funciona completamente dentro de su repositorio Git, por lo que no necesitará ningún tipo de acceso al servidor Perforce (aparte de las credenciales de usuario, por supuesto). Git-p4 no es tan flexible ni completa una solución como Git Fusion, pero le permite hacer la mayor parte de lo que le gustaría hacer sin ser invasivo en el entorno del servidor. -[NOTA] +[NOTE] ====== Necesitará la herramienta `p4` en algún lugar de su` PATH` para trabajar con git-p4. Al momento de escribir esto, está disponible gratuitamente en http://www.perforce.com/downloads/Perforce/20-User[]. diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc index 80404412..229169d3 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -7,7 +7,7 @@ Git se está volviendo popular entre los desarolladores de Windows, y si usted e TFS is a collaboration suite that includes defect and work-item tracking, process support for Scrum and others, code review, and version control. There's a bit of confusion ahead: *TFS* is the server, which supports controlling source code using both Git and their own custom VCS, which they've dubbed *TFVC* (Team Foundation Version Control). Git support is a somewhat new feature for TFS (shipping with the 2013 version), so all of the tools that predate that refer to the version-control portion as ``TFS'', even though they're mostly working with TFVC. -======= + Git se está volviendo popular entre los desarrolladores de Windows, y si estás escribiendo códigos en Windows, hay muchas posibilidades de que estés usando Team Foundation Server (TFS) de Microsoft. TFS es un paquete de colaboración que incluye seguimiento de defectos y elementos de trabajo, soporte de procesos para Scrum y otros, revisión de código y control de versiones. Hay un poco de confusión por delante: * TFS * es el servidor, que admite controlar el código fuente utilizando tanto Git como su propio VCS personalizado, al que han denominado * TFVC * (Team Foundation Version Control). @@ -33,7 +33,7 @@ Sin embargo, su soporte para TFVC es limitado en comparación con git-tfs; por e Entonces, cada herramienta tiene ventajas y desventajas, y hay muchas situaciones que favorecen a una sobre la otra. Cubriremos el uso básico de ambos en este libro. -[NOTA] +[NOTE] ==== Necesitará acceder a un repositorio basado en TFVC para seguir estas instrucciones. Estos no son tan abundantes en la naturaleza como los repositorios de Git o Subversion, por lo que puede necesitar crear uno propio. @@ -144,7 +144,7 @@ Esto tiene la consecuencia de que tus confirmaciones de Git tendrán un hash SHA ===== Git-tf [s] Flujo de trabajo -[NOTA] +[NOTE] ==== Independientemente de la herramienta que esté utilizando, debe establecer un par de valores de configuración de Git para evitar problemas. diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index 4d66ba91..5c6d9f08 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -183,7 +183,7 @@ Lo último que necesita hacer es devolver la línea actual para que pueda pasar return mark ---- -[NOTA] +[NOTE] ==== Si se está ejecutando en Windows, deberá asegurarse de añadir un paso más. Como se ha dicho antes, Windows utiliza CRLF para nuevos carácteres de línea, mientras que git fast-import sólo espera LF. diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index e5af9e46..508adf5f 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -1,5 +1,5 @@ -[[r_plumbing_porcelain]] -=== Fontanería y porcelana +[[r_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. Pero, debido al origen de Git como una caja de herramientas para un VCS en lugar de como un completo y amigable sistema VCS, existen unos cuantos verbos para realizar tareas de bajo nivel y que se diseñaron para poder ser utilizados de forma encadenada al estilo UNIX o para ser utilizados en scripts. @@ -35,4 +35,3 @@ Esto nos deja con cuatro entradas importantes: los archivos `HEAD` e `index` (to 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 á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/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index f9c48a7f..c205a206 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -1,4 +1,5 @@ -=== Interfaces gráficas +[#graphical_interfaces] +=== Interfaces gráficas (((GUIs)))(((Graphical tools))) //// diff --git a/ch04-git-server.asc b/ch04-git-server.asc index 6c898003..395341ac 100644 --- a/ch04-git-server.asc +++ b/ch04-git-server.asc @@ -1,5 +1,5 @@ [#ch04-git-server] -== Git en el Servidor +== Git en el Servidor (((serving repositories))) En este punto, deberías ser capaz de realizar la mayoría de las tareas diarias para las cuales estarás usando Git. diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index cf8752ed..94b75c5c 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -1,5 +1,4 @@ [#ch05-distributed-git] -[[r_distributed_git]] == Git en entornos distribuidos (((distributed git))) diff --git a/ch07-git-tools.asc b/ch07-git-tools.asc index 113728dd..c083abcd 100644 --- a/ch07-git-tools.asc +++ b/ch07-git-tools.asc @@ -35,10 +35,9 @@ include::book/07-git-tools/sections/replace.asc[] include::book/07-git-tools/sections/credentials.asc[] -=== Resumen +=== Resumen Has visto un número de herramientas avanzadas que te permiten manipular tus commits y el área de staging de una manera más precisa. Cuando notes errores, podrás estar en la capacidad de descubrir fácilmente qué commit lo introdujo, cuándo y por quién. Si quieres usar subproyectos en tu proyecto, has aprendido como acomodar esas necesidades. -En este momento, tu debes ser capaz de realizar la mayoría de cosas que vas a necesitar en Git durante tu día a día desde la línea de comandos y sentirte a gusto haciéndolo. - +En este momento, tu debes ser capaz de realizar la mayoría de cosas que vas a necesitar en Git durante tu día a día desde la línea de comandos y sentirte a gusto haciéndolo. diff --git a/ch08-customizing-git.asc b/ch08-customizing-git.asc index a02e11be..bafe4447 100644 --- a/ch08-customizing-git.asc +++ b/ch08-customizing-git.asc @@ -1,5 +1,4 @@ [#ch08-customizing-git] -[[r_customizing_git]] == Personalización de Git Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la diff --git a/ch10-git-internals.asc b/ch10-git-internals.asc index bd6af9a1..ddf5d4b6 100644 --- a/ch10-git-internals.asc +++ b/ch10-git-internals.asc @@ -1,6 +1,6 @@ [#ch10-git-internals] -[[r_git_internals]] -== Los entresijos internos de Git +[[r_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 cuan útil y potente es Git, pero algunas personas opinan que puede ser confuso e innecesariamente complejo para novatos. diff --git a/progit.asc b/progit.asc index 001445a4..edcdf38f 100644 --- a/progit.asc +++ b/progit.asc @@ -2,11 +2,12 @@ Pro Git ======= :doctype: book :docinfo: +:lang: es :toc: :toclevels: 2 :pagenums: :front-cover-image: image:book/cover.png[width=1050,height=1600] -:toc-title: 目次 + ifdef::ebook-format[:leveloffset: -1]