From cadacd93037ece84e8f4d6f006f72e1a5ee91088 Mon Sep 17 00:00:00 2001 From: GWC Date: Fri, 6 Sep 2019 10:24:23 -0300 Subject: [PATCH 1/3] Don't merge this Pull Request. It is a commit for consult --- book/07-git-tools/sections/reset.asc | 152 +++++++++++++-------------- 1 file changed, 76 insertions(+), 76 deletions(-) diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index b1b976b3..2bc2fc7e 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -2,13 +2,13 @@ === Reiniciar Desmitificado Antes de pasar a herramientas más especializadas, hablemos de `reset` y `checkout`. -Estos comandos son dos de las partes más confusas de Git cuando los encuentras por primera vez. Hacen tantas cosas que parece imposible comprenderlas realmente y emplearlas adecuadamente. +Estos comandos son dos de las partes más confusas de Git cuando los encuentras por primera vez. Hacen tantas cosas, que parece imposible comprenderlas realmente y emplearlas adecuadamente. Para esto, recomendamos una metáfora simple. ==== Los Tres Árboles Una manera más fácil de pensar sobre `reset` y `checkout` es a través del marco mental de Git como administrador de contenido de tres árboles diferentes. -Por ``árbol'' aquí realmente queremos decir ``colección de archivos'', no específicamente la estructura de datos. +Por ``árbol'', aquí realmente queremos decir ``colección de archivos'', no específicamente la estructura de datos. (Hay algunos casos donde el índice no funciona exactamente como un árbol, pero para nuestros propósitos es más fácil pensarlo de esta manera por ahora). @@ -26,9 +26,9 @@ Git como sistema maneja y manipula tres árboles en su operación normal: HEAD es el puntero a la referencia de bifurcación actual, que es, a su vez, un puntero al último commit realizado en esa rama. Eso significa que HEAD será el padre del próximo commit que se cree. -En general, es más simple pensar en HEAD como la instantánea de *su última commit*. +En general, es más simple pensar en HEAD como la instantánea de *tu último commit*. -De hecho, es bastante fácil ver cómo se ve esa instantánea. +De hecho, es bastante fácil ver cómo es el aspecto de 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] @@ -52,10 +52,10 @@ Los comandos `cat-file` y `ls-tree` son comandos de ``fontanería'' que se usan [[r_the_index]] ===== El Índice -El índice es su *siguiente commit propuesta*. También nos hemos estado refiriendo a este concepto como el ``Área de Preparación'' de Git ya que esto es lo que Git ve cuando ejecutas `git commit`. +El índice es tu *siguiente commit propuesto*. También nos hemos estado refiriendo a este concepto como el ``Área de Preparación'' de Git ya que esto es lo que Git ve cuando ejecutas `git commit`. -Git rellena este índice con una lista de todos los contenidos del archivo que fueron revisados por última vez en su directorio de trabajo y cómo se veían cuando fueron revisados originalmente. -A continuación, reemplace algunos de esos archivos con nuevas versiones de ellos, y `git commit` los convierte en el árbol para una nueva commit. +Git rellena este índice con una lista de todos los contenidos del archivo que fueron revisados por última vez en tu directorio de trabajo y cómo se veían cuando fueron revisados originalmente. +A continuación, reemplaza algunos de esos archivos con nuevas versiones de ellos, y `git commit` los convierte en el árbol para un nuevo commit. [source,console] ---- @@ -66,16 +66,16 @@ $ git ls-files -s ---- -Nuevamente, aquí estamos usando `ls-files`, que es más un comando entre bastidores que le muestra a qué se parece actualmente su índice. +Nuevamente, aquí estamos usando `ls-files`, que es más un comando entre bastidores que te muestra a qué se parece actualmente el índice. -El índice no es técnicamente una estructura de árbol – en realidad se implementa como un manifiesto aplanado – pero para nuestros propósitos, es lo suficientemente cerca. +El índice no es técnicamente una estructura de árbol – en realidad se implementa como un manifiesto aplanado – pero para nuestros propósitos, está lo suficientemente cerca. ===== El Directorio de Trabajo Finalmente, tienes tu directorio de trabajo. Los otros dos árboles almacenan su contenido de manera eficiente pero inconveniente, dentro de la carpeta `.git`. -El Directorio de trabajo los descomprime en archivos reales, lo que hace que sea mucho más fácil para usted editarlos. -Piense en el Directorio de Trabajo como una *caja de arena*, donde puede probar los cambios antes de enviarlos a su área de ensayo (índice) y luego al historial. +El Directorio de trabajo los descomprime en archivos reales, lo que hace que sea mucho más fácil para ti editarlos. +Piensa en el Directorio de Trabajo como una *caja de arena*, donde puedes probar los cambios antes de enviarlos a tu área de ensayo (índice) y luego al historial. [source,console] ---- @@ -91,7 +91,7 @@ $ tree ==== El Flujo de Trabajo -El objetivo principal de Git es registrar instantáneas de su proyecto en estados sucesivamente mejores, mediante la manipulación de estos tres árboles. +El objetivo principal de Git es registrar instantáneas de tu proyecto en estados sucesivamente mejores, mediante la manipulación de estos tres árboles. image::images/reset-workflow.png[] @@ -103,17 +103,17 @@ image::images/reset-ex1.png[] En este punto, solo el árbol del Directorio de Trabajo tiene cualquier contenido. -Ahora queremos hacer commit a este archivo, por lo que usamos `git add` para tomar contenido en el directorio de trabajo y copiarlo en el índice. +Ahora queremos hacer ``commit'' a este archivo, por lo que usamos `git add` para tomar contenido en el directorio de trabajo y copiarlo en el índice. image::images/reset-ex2.png[] -Luego ejecutamos `git commit`, que toma los contenidos del índice y los guarda como una instantánea permanente, crea un objeto de commit que apunta a esa instantánea y actualiza `master` para apuntar a esa commit. +Luego ejecutamos `git commit`, que toma los contenidos del índice y los guarda como una instantánea permanente, crea un objeto de ``commit'' que apunta a esa instantánea y actualiza `master` para apuntar a ese ``commit''. image::images/reset-ex3.png[] Si ejecutamos `git status`, no veremos ningún cambio, porque los tres árboles son iguales. -Ahora queremos hacer un cambio en ese archivo y hacerle commit. +Ahora queremos hacer un cambio en ese archivo y hacerle un nuevo ``commit''. Pasaremos por el mismo proceso; primero, cambiamos el archivo en nuestro directorio de trabajo. Llamemos a esto *v2* del archivo, y lo indicamos en rojo. @@ -125,74 +125,74 @@ A continuación, ejecutamos `git add` para ubicarlo en nuestro índice. image::images/reset-ex5.png[] En este punto si ejecutamos `git status` veremos el archivo en verde -debajo de ``Changes to be committed'' porque el Índice y el HEAD difieren – es decir, nuestro siguiente commit propuesta ahora es diferente de nuestra última commit. -Finalmente, ejecutamos `git commit` para finalizar el commit. +debajo de ``Changes to be committed'' porque el Índice y el HEAD difieren – es decir, nuestro siguiente ``commit'' propuesto ahora es diferente de nuestro último ``commit''. +Finalmente, ejecutamos `git commit` para finalizar el ``commit''. image::images/reset-ex6.png[] Ahora `git status` no nos dará salida, porque los tres árboles son iguales nuevamente. El cambio de ramas o la clonación pasa por un proceso similar. -Cuando verifica una rama, eso cambia *HEAD* para que apunte a la nueva ref de la rama, rellena su *Índice* con la instantánea de esa confirmación, luego copia los contenidos del *Índice* en su *Directorio de Trabajo*. +Cuando verifica una rama, eso cambia *HEAD* para que apunte a la nueva ``ref'' de la rama, rellena su *Índice* con la instantánea de esa confirmación, luego copia los contenidos del *Índice* en tu *Directorio de Trabajo*. ==== El Papel del Reinicio El comando `reset` tiene más sentido cuando se ve en este contexto. -A los fines de estos ejemplos, digamos que hemos modificado `file.txt` de nuevo y lo hemos hecho commit por tercera vez. Entonces ahora nuestra historia se ve así: +A los fines de estos ejemplos, digamos que hemos modificado `file.txt` de nuevo y le hemos hecho ``commit'' por tercera vez. Entonces ahora nuestra historia se ve así: image::images/reset-start.png[] -Caminemos ahora a través de exactamente lo que `reset` hace cuando lo llama. Manipula directamente estos tres árboles de una manera simple y predecible. +Hablemos ahora sobre lo que `reset` hace exactamente cuando es llamado. Manipula directamente estos tres árboles de una manera simple y predecible. Hace hasta tres operaciones básicas. ===== Paso 1: mover HEAD -Lo primero que `reset` hará es mover a lo que HEAD apunta. -Esto no es lo mismo que cambiar HEAD en sí mismo (que es lo que hace `checkout`); `reset` mueve la rama a la que HEAD apunta. -Esto significa que si HEAD está configurado en la rama `master` (es decir, usted está actualmente en la rama `master`), ejecutar `git reset 9e5e64a` comenzará haciendo que `master` apunte a `9e5e64a`. +Lo primero que `reset` hará es mover a lo que *HEAD* apunta. +Esto no es lo mismo que cambiar *HEAD* en sí mismo (que es lo que hace `checkout`), `reset` mueve la rama a la que *HEAD* apunta. +Esto significa que si HEAD está configurado en la rama `master` (es decir, estás actualmente en la rama `master`), ejecutar `git reset 9e5e64a` comenzará haciendo que `master` apunte a `9e5e64a`. image::images/reset-soft.png[] -No importa qué forma de `reset` con un commit invoque ustéd, esto es lo primero que siempre intentará hacer. +No importa qué forma de `reset` invoques con un ``commit, esto es lo primero que siempre intentará hacer. Con `reset --soft`, simplemente se detendrá allí. -Ahora tómese un segundo para mirar ese diagrama y darse cuenta de lo que sucedió: esencialmente deshizo el último comando `git commit`. -Cuando ejecuta `git commit`, Git crea una nueva confirmación y mueve la rama a la que apunta HEAD. -Cuando haces `reset` de vuelta a `HEAD~` (el padre de HEAD), está volviendo a colocar la rama donde estaba, sin cambiar el índice o el Directorio de Trabajo. -Ahora puedes actualizar el índice y ejecutar `git commit` nuevamente para lograr lo que `git commit --amend` hubiera hecho (ver <>). +Ahora tómate un segundo para mirar ese diagrama y darte cuenta de lo que sucedió: esencialmente deshizo el último comando `git commit`. +Cuando ejecutas `git commit`, Git crea una nueva confirmación y mueve la rama a la que apunta *HEAD*. +Cuando haces `reset` de vuelta a `HEAD~` (el padre de *HEAD*), está volviendo a colocar la rama donde estaba, sin cambiar el *Índice* o el Directorio de Trabajo. +Ahora puedes actualizar el *Índice* y ejecutar `git commit` nuevamente para lograr lo que `git commit --amend` hubiera hecho (ver <>). ===== Paso 2: Actualizando el índice (--mixed) -Tenga en cuenta que si ejecuta `git status` ahora verá en verde la diferencia entre el Índice y lo que el nuevo HEAD es. +Ten en cuenta que si ejecutas `git status` ahora, verás en verde la diferencia entre el *Índice* y lo que el nuevo *HEAD* es. -Lo siguiente que `reset` hará es actualizar el Índice con los contenidos de cualquier instantánea que HEAD señale ahora. +Lo siguiente que `reset` hará es actualizar el *Índice* con los contenidos de cualquier instantánea que *HEAD* señale ahora. image::images/reset-mixed.png[] -Si especifica la opción `--mixed`, `reset` se detendrá en este punto. -Este también es el por defecto, por lo que si no especifica ninguna opción (solo `git reset HEAD~` en este caso), aquí es donde el comando se detendrá. +Si especificas la opción `--mixed`, `reset` se detendrá en este punto. +Este también es el comportamiento por defecto, por lo que si no especificas ninguna opción (sólo `git reset HEAD~`, en este caso), aquí es donde el comando se detendrá. -Ahora tómese otro segundo para mirar ese diagrama y darse cuenta de lo que sucedió: todavía deshizo su último `commit`, pero también hizo _unstaged_ de todo. -Retrocedió a antes de ejecutar todos sus comandos `git add` y `git commit`. +Ahora tómate otro segundo para mirar ese diagrama y darte cuenta de lo que sucedió: deshizo tu último `commit` y también hizo _unstaged_ de todo. +Retrocedió a antes de ejecutar todos los comandos `git add` y `git commit`. ===== Paso 3: Actualizar el Directorio de Trabajo (--hard) -Lo tercero que `reset` hará es hacer que el Directorio de Trabajo se parezca al Índice. -Si usa la opción `--hard`, continuará en esta etapa. +Lo tercero que `reset` hará es hacer que el *Directorio de Trabajo* se parezca al *Índice*. +Si usas la opción `--hard`, continuará en esta etapa. image::images/reset-hard.png[] Entonces, pensemos en lo que acaba de pasar. -Deshizo su último commit, los comandos `git add` y `git commit`, **y** todo el trabajo que hizo en su directorio de trabajo. +Deshizo tu último commit, los comandos `git add` y `git commit`, **y** todo el trabajo que realizaste en tu *Directorio de Trabajo*. Es importante tener en cuenta que este indicador (`--hard`) es la única manera de hacer que el comando `reset` sea peligroso, y uno de los pocos casos en que Git realmente destruirá los datos. -Cualquier otra invocación de `reset` puede deshacerse fácilmente, pero la opción `--hard` no puede, ya que sobrescribe forzosamente los archivos en el Directorio de Trabajo. -En este caso particular, todavía tenemos la versión *v3* de nuestro archivo en una commit en nuestro DB de Git, y podríamos recuperarla mirando nuestro `reflog`, pero si no le hubiéramos hecho commit, Git hubiese sobrescrito el archivo y sería irrecuperable. +Cualquier otra invocación de `reset` puede deshacerse fácilmente, pero la opción `--hard` no puede, ya que sobrescribe forzosamente los archivos en el *Directorio de Trabajo*. +En este caso particular, todavía tenemos la versión *v3* de nuestro archivo en un ``commit'' en nuestro *DB* de Git, y podríamos recuperarla mirando nuestro `reflog`, pero si no le hubiéramos hecho ``commit'', Git hubiese sobrescrito el archivo y sería irrecuperable. ===== Resumen -El comando `reset` sobrescribe estos tres árboles en un orden específico, deteniéndose cuando ustéd le dice: +El comando `reset` sobrescribe estos tres árboles en un orden específico, deteniéndose cuando se le dice: 1. Mueva los puntos HEAD de la rama a _(deténgase aquí si `--soft`)_ 2. Haga que el Índice se vea como HEAD _(deténgase aquí a menos que `--hard`)_ @@ -200,10 +200,10 @@ El comando `reset` sobrescribe estos tres árboles en un orden específico, dete ==== Reiniciar Con una Ruta -Eso cubre el comportamiento de `reset` en su forma básica, pero también puede proporcionarle una ruta para actuar. -Si especifica una ruta, `reset` omitirá el paso 1 y limitará el resto de sus acciones a un archivo o conjunto específico de archivos. -Esto realmente tiene sentido – HEAD es solo un puntero, y no se puede apuntar a una parte de una commit y parte de otra. -Pero el índice y el Directorio de Trabajo _pueden_ actualizarse parcialmente, por lo que el reinicio continúa con los pasos 2 y 3. +Eso cubre el comportamiento de `reset` en su forma básica, pero también puedes proporcionarle una ruta para actuar. +Si especificas una ruta, `reset` omitirá el paso 1 y limitará el resto de sus acciones a un archivo o conjunto específico de archivos. +Esto realmente tiene sentido – HEAD es solo un puntero, y no se puede apuntar a sólo una parte de un ``commit'' y otra parte de otro. +Pero el *Índice* y el *Directorio de Trabajo* _pueden_ actualizarse parcialmente, por lo que el reinicio continúa con los pasos 2 y 3. Entonces, supongamos que ejecutamos `git reset file.txt`. Este formulario (ya que no especificó un commit SHA-1 o una rama, y no especificó `--soft` o `--hard`) es una abreviatura de `git reset --mixed HEAD file.txt`, la cual hará: @@ -211,7 +211,7 @@ Este formulario (ya que no especificó un commit SHA-1 o una rama, y no especifi 1. Mueva los puntos HEAD de la rama a _(omitido)_ 2. Haga que el Índice se vea como HEAD _(deténgase aquí)_ -Por lo tanto, básicamente solo copia `archivo.txt` de HEAD al Índice. +Por lo tanto, básicamente solo copia `archivo.txt` de *HEAD* al *Índice*. image::images/reset-path1.png[] @@ -223,81 +223,81 @@ image::images/reset-path2.png[] Esta es la razón por la cual el resultado del comando `git status` sugiere que ejecute esto para descentralizar un archivo. (Consulte <> para más sobre esto). -Igualmente podríamos no permitir que Git suponga que queríamos ``extraer los datos de HEAD'' especificando una commit específica para extraer esa versión del archivo. +Igualmente podríamos no permitir que Git suponga que queríamos ``extraer los datos de HEAD'' especificando un ``commit'' específico para extraer esa versión del archivo. Simplemente ejecutaríamos algo como `git reset eb43bf file.txt`. image::images/reset-path3.png[] -Esto efectivamente hace lo mismo que si hubiéramos revertido el contenido del archivo a *v1* en el Directorio de Trabajo, ejecutáramos `git add` en él, y luego lo revertimos a *v3* nuevamente (sin tener que ir a través de todos esos pasos) -Si ejecutamos `git commit` ahora, registrará un cambio que revierte ese archivo de vuelta a *v1*, aunque nunca más lo volvimos a tener en nuestro Directorio de Trabajo. +Esto efectivamente hace lo mismo que si hubiéramos revertido el contenido del archivo a *v1* en el *Directorio de Trabajo*, ejecutado `git add` en él, y luego lo revertimos a *v3* nuevamente (sin tener que ir a través de todos esos pasos) +Si ejecutamos `git commit` ahora, registrará un cambio que revierte ese archivo de vuelta a *v1*, aunque nunca más lo volvimos a tener en nuestro *Directorio de Trabajo*. -También es interesante observar que, como `git add`, el comando `reset` aceptará una opción `--patch` para hacer unstage del contenido en una base hunk-by-hunk. -Por lo tanto, puede hacer unstage o revertir el contenido de forma selectiva. +También es interesante observar que, como `git add`, el comando `reset` aceptará una opción `--patch` para hacer _unstage_ del contenido en una base hunk-by-hunk. +Por lo tanto, puede hacer _unstage_ o revertir el contenido de forma selectiva. ==== Aplastando -Veamos cómo hacer algo interesante con este poder recién descubierto – aplastando commits. +Veamos cómo hacer algo interesante con este poder recién descubierto – aplastando ``commits''. -Supongamos que tiene una serie de confirmaciones con mensajes como ``oops.'', ``WIP'' y ``se olvidó de este archivo''. +Supongamos que tienes una serie de confirmaciones con mensajes como ``oops.'', ``WIP'' y ``se olvidó de este archivo''. Puedes usar `reset` para aplastarlos rápida y fácilmente en una sola confirmación que lo hace ver realmente inteligente. (<<_aplastando>> muestra otra forma de hacerlo, pero en este ejemplo es más simple usar `reset`.) -Supongamos que tiene un proyecto en el que la primera commit tiene un archivo, la segunda commit agregó un nuevo archivo y cambió la primera, y la tercera commit cambió el primer archivo otra vez. -La segunda commit fué un trabajo en progreso y quiere aplastarlo. +Supongamos que tiene un proyecto en el que el primer ``commit'' tiene un archivo, el segundo ``commit'' agregó un nuevo archivo y cambió el primero, y el tercer ``commit'' cambió el primer archivo otra vez. +El segundo ``commit'' fue un trabajo en progreso y quieres aplastarlo. image::images/reset-squash-r1.png[] -Puede ejecutar `git reset --soft HEAD~2` para mover la rama HEAD a una commit anterior (la primera commit que desea mantener): +Puedes ejecutar `git reset --soft HEAD~2` para mover la rama HEAD a un ``commit'' anterior (el primer ``commit'' que deseas mantener): image::images/reset-squash-r2.png[] -Y luego simplemente ejecute `git commit` nuevamente: +Y luego simplemente ejecuta `git commit` nuevamente: image::images/reset-squash-r3.png[] -Ahora puede ver que su historial alcanzable, la historia que empujaría, ahora parece que tuvo una commit con `archivo-a.txt` v1, luego un segundo que ambos modificaron `archivo-a.txt` a v3 y agregaron `archivo-b.txt`. La commit con la versión v2 del archivo ya no está en el historial. +Ahora puedes ver que el historial alcanzable, la historia que empujarías, ahora parece que tuvo un ``commit'' con `archivo-a.txt` v1, luego un segundo que ambos modificaron `archivo-a.txt` a v3 y agregaron `archivo-b.txt`. El ``commit'' con la versión v2 del archivo ya no está en el historial. ==== Echale Un vistazo -Finalmente, puede preguntarse cuál es la diferencia entre `checkout` y `reset`. -Al igual que `reset`, `checkout` manipula los tres árboles, y es un poco diferente dependiendo de si le da al comando una ruta de archivo o no. +Finalmente, puedes preguntarte cuál es la diferencia entre `checkout` y `reset`. +Al igual que `reset`, `checkout` manipula los tres árboles, y es un poco diferente dependiendo de si se le da al comando una ruta de archivo o no. ===== Sin Rutas Ejecutar `git checkout [branch]` es bastante similar a ejecutar `git reset --hard [branch]` porque actualiza los tres árboles para que se vea como `[branch]`, pero hay dos diferencias importantes. -Primero, a diferencia de `reset --hard`, `checkout` está directorio-de-trabajo seguro; Verificará para asegurarse de que no está volando los archivos que tienen cambios en ellos. -En realidad, es un poco más inteligente que eso – intenta hacer una fusión trivial en el Directorio de Trabajo, por lo que todos los archivos que _no haya_ cambiado serán actualizados. +Primero, a diferencia de `reset --hard`, `checkout` está en el *directorio-de-trabajo* seguro; Verificará para asegurarse de que no está volando los archivos que tienen cambios en ellos. +En realidad, es un poco más inteligente que eso – intenta hacer una fusión trivial en el *Directorio de Trabajo*, por lo que todos los archivos que _no hayan_ cambiado serán actualizados. `reset --hard`, por otro lado, simplemente reemplazará todo en general sin verificar. -La segunda diferencia importante es cómo actualiza HEAD. -Donde `reset` moverá la rama a la que HEAD apunta, `checkout` moverá HEAD para señalar otra rama. +La segunda diferencia importante es cómo actualiza *HEAD*. +Donde `reset` moverá la rama a la que *HEAD* apunta, `checkout` moverá *HEAD* para señalar otra rama. -Por ejemplo, digamos que tenemos las ramas `master` y `develop` que apuntan a diferentes commits, y actualmente estamos en `develop` (así que HEAD lo señala). -Si ejecutamos `git reset master`, `develop` ahora apuntará a la misma commit que `master`. -Si en cambio ejecutamos `git checkout master`, `develop` no se mueve, HEAD sí lo hace. -HEAD ahora apuntará a `master`. +Por ejemplo, digamos que tenemos las ramas `master` y `develop` que apuntan a diferentes 'commits', y actualmente estamos en `develop` (así que HEAD la señala). +Si ejecutamos `git reset master`, `develop` ahora apuntará al mismo ``commit'' que `master`. +Si en cambio ejecutamos `git checkout master`, `develop` no se mueve, *HEAD* sí lo hace. +*HEAD* ahora apuntará a `master`. -Entonces, en ambos casos estamos moviendo HEAD para apuntar a la commit A, pero _cómo_ lo hacemos es muy diferente. -`reset` moverá los puntos HEAD de la rama a, `checkout` mueve el mismo HEAD. +Entonces, en ambos casos estamos moviendo *HEAD* para apuntar al ``commit'' A, pero el _cómo_ lo hacemos es muy diferente. +`reset` moverá los puntos *HEAD* de la rama A, `checkout` mueve el mismo HEAD. image::images/reset-checkout.png[] ===== Con Rutas -La otra forma de ejecutar `checkout` es con una ruta de archivo, que, como `reset`, no mueva HEAD. -Es como `git reset [branch] file` en que actualiza el índice con ese archivo en esa commit, pero también sobrescribe el archivo en el directorio de trabajo. -Sería exactamente como `git reset --hard [branch] file` (si `reset` le permitiera ejecutar eso) - no está directorio-de-trabajo seguro, y no mueve a HEAD. +La otra forma de ejecutar `checkout` es con una ruta de archivo, que como `reset`, no mueva *HEAD*. +Es como `git reset [branch] file` en que actualiza el índice con ese archivo en ese ``commit'', pero también sobrescribe el archivo en el *Directorio de Trabajo*. +Sería exactamente como `git reset --hard [branch] file` (si `reset` permitiera ejecutar eso) - no está directorio-de-trabajo seguro, y no mueve a *HEAD*. -Además, al igual que `git reset` y `git add`, `checkout` aceptará una opción `--patch` para permitirle revertir selectivamente el contenido del archivo sobre una base hunk-by-hunk. +Además, al igual que `git reset` y `git add`, `checkout` aceptará una opción `--patch` para permitir revertir selectivamente el contenido del archivo sobre una base hunk-by-hunk. ==== Resumen -Esperemos que ahora entienda y se sienta más cómodo con el comando `reset`, pero probablemente todavía esté un poco confundido acerca de cómo exactamente difiere de `checkout` y posiblemente no pueda recordar todas las reglas de las diferentes invocaciones. +Esperamos que ahora entiendas y te sientas más cómodo con el comando `reset`, pero probablemente todavía estés un poco confundido acerca de cómo exactamente difiere de `checkout` y posiblemente no puedas recordar todas las reglas de las diferentes invocaciones. -Aquí hay una hoja de trucos para cuales comandos afectan a cuales árboles. -La columna ``HEAD'' lee ``REF'' si ese comando mueve la referencia (rama) a la que HEAD apunta, y ``HEAD'' si mueve al mismo HEAD. +Aquí hay una hoja de trucos para cuáles comandos afectan a cuáles árboles. +La columna ``HEAD'' lee ``REF'' si ese comando mueve la referencia (rama) a la que *HEAD* apunta, y ``HEAD'' si se mueve al mismo *HEAD*. Esta función calculará la ciudad y el país del visitante desde la dirección IP. Para activar esta función, debes descargar la base de datos GeoIP y configurar la clave de la API de Google. Por favor, vea "Más información" [options="header", cols="3,1,1,1,1"] From f5aed6c6fa5fb09c0b0e7b97420bac00d9367deb Mon Sep 17 00:00:00 2001 From: GWC Date: Fri, 6 Sep 2019 10:25:18 -0300 Subject: [PATCH 2/3] Don't merge this Pull Request. It is a commit for consult --- book/07-git-tools/sections/reset.asc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 2bc2fc7e..ffe6feba 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -298,7 +298,9 @@ Esperamos que ahora entiendas y te sientas más cómodo con el comando `reset`, Aquí hay una hoja de trucos para cuáles comandos afectan a cuáles árboles. La columna ``HEAD'' lee ``REF'' si ese comando mueve la referencia (rama) a la que *HEAD* apunta, y ``HEAD'' si se mueve al mismo *HEAD*. +**<<[begin:] No encuentro el sentido de esta orción** Esta función calculará la ciudad y el país del visitante desde la dirección IP. Para activar esta función, debes descargar la base de datos GeoIP y configurar la clave de la API de Google. Por favor, vea "Más información" +**[:endig]>>** [options="header", cols="3,1,1,1,1"] |================================ From 354470b3797f90f08338c791e52baa1e52351e29 Mon Sep 17 00:00:00 2001 From: GWC Date: Mon, 9 Sep 2019 19:26:12 -0300 Subject: [PATCH 3/3] Finished review on Section '07-git-tools' --- book/07-git-tools/sections/reset.asc | 10 +- .../sections/revision-selection.asc | 98 +++++++++---------- .../sections/rewriting-history.asc | 96 +++++++++--------- book/07-git-tools/sections/searching.asc | 26 ++--- book/07-git-tools/sections/signing.asc | 24 ++--- .../sections/stashing-cleaning.asc | 52 +++++----- book/07-git-tools/sections/submodules.asc | 85 ++++++++-------- book/07-git-tools/sections/subtree-merges.asc | 28 +++--- 8 files changed, 209 insertions(+), 210 deletions(-) diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index ffe6feba..a1a06c2f 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -297,15 +297,13 @@ Además, al igual que `git reset` y `git add`, `checkout` aceptará una opción Esperamos que ahora entiendas y te sientas más cómodo con el comando `reset`, pero probablemente todavía estés un poco confundido acerca de cómo exactamente difiere de `checkout` y posiblemente no puedas recordar todas las reglas de las diferentes invocaciones. Aquí hay una hoja de trucos para cuáles comandos afectan a cuáles árboles. -La columna ``HEAD'' lee ``REF'' si ese comando mueve la referencia (rama) a la que *HEAD* apunta, y ``HEAD'' si se mueve al mismo *HEAD*. -**<<[begin:] No encuentro el sentido de esta orción** -Esta función calculará la ciudad y el país del visitante desde la dirección IP. Para activar esta función, debes descargar la base de datos GeoIP y configurar la clave de la API de Google. Por favor, vea "Más información" -**[:endig]>>** +La columna ``HEAD'' dice ``REF'' si ese comando mueve la referencia (rama) a la que *HEAD* apunta, y ``HEAD'' si se mueve al propio *HEAD*. +Presta especial atención a la columna **WD Safe**: si dice **NO** , tómate un segundo para pensar antes de ejecutar ese comando. [options="header", cols="3,1,1,1,1"] |================================ -| | HEAD | Índice | Dirtrabajo | DT Seguro? -| *Nivl de la Commit* | | | | +| | HEAD | Index | Workdir | WD Safe? +| *Nivel de Commit* | | | | | `reset --soft [commit]` | REF | NO | NO | SI | `reset [commit]` | REF | SI | NO | SI | `reset --hard [commit]` | REF | SI | SI | *NO* diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 47e03e21..531c425a 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -1,19 +1,19 @@ [[r_revision_selection]] -=== Revisión por selección +=== Revisión por selección -Git te permite especificar ciertos commits o un rango de estos en muchas maneras. +Git te permite especificar ciertos 'commits' o un rango de éstos de muchas maneras. No son necesariamente obvias, pero es útil conocerlas. -==== Revisiones individuales +==== Revisiones individuales -Obviamente se puede referir a un commit por el hash SHA-1 que se le asigna, pero también existen formas más amigables de referirse a los commits. -Esta sección delinea varias maneras en las que se puede referir a un commit indiviual. +Obviamente se puede referir a un ``commit'' por el hash SHA-1 que se le asigna, pero también existen formas más amigables de referirse a los 'commits'. +Esta sección delinea varias maneras en las que se puede referir a un ``commit'' indiviual. ==== SHA-1 corto -Git es lo suficientemente inteligente como para descifrar el commit al que te refieres si le entregas los primeros caracteres, siempre y cuando la parte de SHA-1 sea de al menos 4 caracteres y no sea ambigua - esto quiere decir, que solamente un objeto en el repositorio actual comience con ese SHA-1 parcial. +Git es lo suficientemente inteligente como para descifrar el ``commit'' al que te refieres si le entregas los primeros caracteres, siempre y cuando la parte de SHA-1 sea de al menos 4 caracteres y no sea ambigua - esto quiere decir, que solamente un objeto en el repositorio actual comience con ese SHA-1 parcial. -Por ejemplo, para ver un commit específico, supongamos que se utiliza el comando `git log` y se identifica el commit donde se agregó cierta funcionalidad: +Por ejemplo, para ver un ``commit'' específico, supongamos que se utiliza el comando `git log` y se identifica el ``commit'' donde se agregó cierta funcionalidad: [source,console] ---- @@ -38,7 +38,7 @@ Date: Thu Dec 11 14:58:32 2008 -0800 added some blame and merge stuff ---- -En este caso, se escoge `1c002dd....`. Si usted utiliza `git show` en ese commit, los siguientes comandos son iguales ( asumiendo que las versiones cortas no son ambiguas): +En este caso, se escoge `1c002dd....`. Si utilizas `git show` en ese ``commit'', los siguientes comandos son iguales ( asumiendo que las versiones cortas no son ambiguas): [source,console] ---- @@ -48,7 +48,7 @@ $ git show 1c002d ---- Git puede descubrir una abreviación corta y única del valor SHA-1. -Si usted añade `--abbrev-commit` al comando `git log`, el resultado utilizará los valores cortos pero manteniendolos únicos; por default utiliza siete caracteres pero los hace más largos de ser necesario para mantener el SHA-1 sin ambigüedades: +Si añades `--abbrev-commit` al comando `git log`, el resultado utilizará los valores cortos pero manteniéndolos únicos; por default utiliza siete caracteres pero los hace más largos de ser necesario para mantener el SHA-1 sin ambigüedades: [source,console] ---- @@ -58,18 +58,18 @@ ca82a6d changed the version number a11bef0 first commit ---- -Generalmente, de ocho a diez caracteres son más que suficientes para ser únicos en un proyecto. +Generalmente, de ocho a diez caracteres son más que suficientes para ser únicos en un proyecto. -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. +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 NOTE RESPECTO A SHA-1 +.UNA BREVE NOTA 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. +Mucha gente se preocupa de que en cierto momento, fruto del azar, tendrán dos objetos en su repositorio cuyos hash tendrán el mismo valor SHA-1. Pero, ¿entonces qué? -Si sucede que realizas un commit y el objeto tiene el mismo hash que un objeto previo en tu repositorio, Git verá el objeto previo en tu base de datos y asumirá que ya estaba escrito. +Si sucede que realizas un ``commit'' y el objeto tiene el mismo hash que un objeto previo en tu repositorio, Git verá el objeto previo en tu base de datos y asumirá que ya estaba escrito. Si intentas mirar el objeto otra vez, siempre tendrás la data del primer objeto. Sin embargo, debes ser consciente de cuán ridículamente improbable es este escenario. El digest SHA-1 es de 20 bytes o 160 bits. El número de objetos aleatorios necesario para asegurar un 50% de probabilidades de una única colisión bordea el 2^80^ @@ -79,15 +79,15 @@ o 1 millón de millones de millones. Esto es 1,200 veces el ńumero de granos de Aquí hay un ejemplo para darte una idea de lo que tomaría para conseguir una colisión de SHA-1. Si todos los 6.5 mil millones de humanos en la Tierra estuvieran programando, y cada segundo, cada uno produjera el código equivalente a toda la historia del kernel Linux (3.6 mil millones de objetos en Git) e hicieran push en un enorme repositorio Git, tomaría aproximadamente 2 años hasta que el repositorio tuviera suficientes objetos para un 50% de probabilidades de que ocurriera una única colisión en los SHA-1 de los objetos. -Existe una probabilidad más alta de que cada miembro de tu equipo de programación sea atacado y asesinado por lobos en incidentes sin relación y todo esto en la misma noche. +Existe una probabilidad más alta de que cada miembro de tu equipo de programación sea atacado y asesinado por lobos en incidentes sin relación y todo esto en la misma noche. ==== [[r_branch_references]] -==== Referencias por rama +==== Referencias por rama -El camino más sencillo para especificar un commit requiere que este tenga una rama de referencia apuntando al mismo. -Entonces, se puede usar el nombre de la rama en cualquier comando Git que espere un objeto commit o un valor SHA-1. -Por ejemplo, si se quiere mostrar el último objeto commit de una rama, los siguientes comandos son equivalentes, asumiendo que la rama `topic1` apunta a `ca82a6d`: +El camino más sencillo para especificar un ``commit'' requiere que este tenga una rama de referencia apuntando al mismo. +Entonces, se puede usar el nombre de la rama en cualquier comando Git que espere un objeto ``commit'' o un valor SHA-1. +Por ejemplo, si se quiere mostrar el último objeto ``commit'' de una rama, los siguientes comandos son equivalentes, asumiendo que la rama `topic1` apunta a `ca82a6d`: [source,console] ---- @@ -106,9 +106,9 @@ ca82a6dff817ec66f44342007202690a93763949 ---- [[r_git_reflog]] -==== Nombres cortos de RefLog +==== Nombres cortos de RefLog -Una de las cosas que Git hace en segundo plano mientras tu estás trabajando a distancia es mantener un ``reflog'' - un log de a dónde se apuntan las referencias de tu HEAD y tu rama en los últimos meses. +Una de las cosas que Git hace en segundo plano, mientras tu estás trabajando a distancia, es mantener un ``reflog'' - un log de a dónde se apuntan las referencias de tu HEAD y tu rama en los últimos meses. Se puede ver el reflog utilizando `git reflog`: @@ -125,7 +125,7 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. ---- Cada vez que la punta de tu rama es actualizada por cualquier razón, Git guarda esa información en este historial temporal. -Y es así como se puede especificar commits antiguos con esta información. +Y es así como se puede especificar 'commits' antiguos con esta información. Si se quiere ver el quinto valor anterior a tu HEAD en el repositorio, se puede usar la referencia `@{n}` que se ve en la salida de reflog: [source,console] @@ -142,9 +142,9 @@ $ git show master@{yesterday} ---- Esto muestra a dónde apuntaba tu rama el día de ayer. -Esta técnica solo funciona para información que permanece en tu reflog, por lo que no se puede utilizar para ver commits que son anteriores a los que aparecen en él. +Esta técnica solo funciona para información que permanece en tu 'reflog', por lo que no se puede utilizar para ver 'commits' que son anteriores a los que aparecen en él. -Para ver información sobre reflog en el formato de `git log`, se puede utilizar `git log -g`: +Para ver información sobre 'reflog' en el formato de `git log`, se puede utilizar `git log -g`: [source,console] ---- @@ -166,14 +166,14 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -Es importante notar que la información de reflog es estríctamente local - es un log de lo que se ha hecho en el repositorio local. -Las referencias no serán las mismas en otra copia del repositorio; y justo después de que se ha inicializado el repositorio, se tendrá un reflog vacío, dado que no ha ocurrido ninguna actividad todavía en el mismo. -Utilizar `git show HEAD@{2.months.ago}` funcionará solo si se clonó el projecto hace al menos dos meses - si se clonó hace cinco minutos, no se obtendrán resultados. +Es importante notar que la información de 'reflog' es estríctamente local - es un log de lo que se ha hecho en el repositorio local. +Las referencias no serán las mismas en otra copia del repositorio; y justo después de que se ha inicializado el repositorio, se tendrá un 'reflog' vacío, dado que no ha ocurrido ninguna actividad todavía en el mismo. +Utilizar `git show HEAD@{2.months.ago}` funcionará solo si se clonó el proyecto hace al menos dos meses - si se clonó hace cinco minutos, no se obtendrán resultados. ==== Referencias por ancestros -Otra forma principal de especificar un commit es por sus ancestros. -Si se coloca un `^` al final de la referencia, Git lo resuelve como el padre de ese commit. +Otra forma principal de especificar un ``commit'' es por sus ancestros. +Si se coloca un `^` al final de la referencia, Git lo resuelve como el padre de ese ``commit''. Supongamos que se mira a la historia de un proyecto: [source,console] @@ -204,7 +204,7 @@ Date: Thu Dec 11 15:08:43 2008 -0800 También se puede especificar un número despúes de `^` - por ejemplo, `d921970^2` significa ``el segundo padre de d921970.'' Esta sintaxis es útil solamente para fusiones confirmadas, las cuales tienen más de un padre. -El primer padre es la rama en el que se estaba al momento de fusionar, y el segundo es el commit en la rama en la que se fusionó: +El primer padre es la rama en el que se estaba al momento de fusionar, y el segundo es el ``commit'' en la rama en la que se fusionó: [source,console] ---- @@ -256,22 +256,22 @@ También se puede combinar estas sintaxis - se puede obtener el segundo padre de [[r_commit_ranges]] ==== Rangos de Commits -Ahora que ya puede especificar commits individuales, vamos a a ver cómo especificar un rango de commits. +Ahora que ya puede especificar 'commits' individuales, vamos a a ver cómo especificar un rango de 'commits'. Esto es particularmete útil para administrar las ramas - si se tienen muchas ramas, se puede usar un rango de especificaciones para contestar preguntas como, ``¿Qué trabajo está en esta rama y cuál no hemos fusionado en la rama principal?'' ===== Dos puntos La forma más común de especificar un rango es mediante la sintaxis de doble punto. -Esto básicamente pide a Git que resuelva un rango de commits que es alcanzable desde un commit pero que no es alcanzable desde otro. -Por ejemplo, digamos que se tiene un historial de commits que se ve como <>. +Esto básicamente pide a Git que resuelva un rango de 'commits' que es alcanzable desde un ``commit'' pero que no es alcanzable desde otro. +Por ejemplo, digamos que se tiene un historial de 'commits' que se ve como <>. [[rdouble_dot]] .Example history for range selection. image::images/double-dot.png[Ejemplo historial para un rango de seleción.] Se quiere ver qué se encuentra en la rama experiment que no ha sido fusionado a la rama master todavía. -Se puede pedir a Git que muestre el log de solamente aquellos commits con `master..experiment` - eso significa ``todos los commits alcanzables por experiment que no son alcanzables por master.'' -Para ser breves y claros en este ejemplo. Se usarán las letras de los objetos commit del diagrama en lugar del log para que se muestre de la siguiente manera: +Se puede pedir a Git que muestre el log de solamente aquellos 'commits' con `master..experiment` - eso significa ``todos los commits alcanzables por experiment que no son alcanzables por master.'' +Para ser breves y claros en este ejemplo. Se usarán las letras de los objetos ``commit'' del diagrama en lugar del log para que se muestre de la siguiente manera: [source,console] ---- @@ -281,7 +281,7 @@ C ---- Si, por otro lado, se quiere lo opuesto - todos los commits en `master` que no están en `experiment` - se pueden invertir los nombres de las ramas. -`experiment..mater``muestra todo lo que hay en `master` que no es alcanzable para `experiment`: +`experiment..master``muestra todo lo que hay en `master` que no es alcanzable para `experiment`: [source,console] ---- @@ -298,15 +298,15 @@ Otro uso bastante frecuente de esta sintaxis es para ver lo que se está a punto $ git log origin/master..HEAD ---- -Este comando muestra cualquier commit en tu rama actual que no está en la rama `master` del remoto `origin`. -Si se corre un `git push` y la rama de seguimiento actual es `origin/master`, los commits listados por `git log origin/master..HEAD` son los commits que serán transferidos al servidor. -También se puede dejar de lado de la sintaxis para que Git asuma HEAD. -Por ejemplo, se puede obtener el mismo resultado que en el ejemplo previo tipiando `git log origin/master..` - Git sustituye HEAD is un lado está faltando. +Este comando muestra cualquier ``commit'' en tu rama actual que no está en la rama `master` del remoto `origin`. +Si se corre un `git push` y la rama de seguimiento actual es `origin/master`, los 'commits' listados por `git log origin/master..HEAD` son los 'commits' que serán transferidos al servidor. +También se puede dejar de lado la sintaxis para que Git asuma la HEAD. +Por ejemplo, se puede obtener el mismo resultado que en el ejemplo previo tipiando `git log origin/master..` - Git sustituye HEAD si un lado está faltando. ===== Múltiples puntos -La sintaxis de dos puntos es útil como una abreviatura; pero tal vez se desea especificar más de dos ramas para indicar la revisión, como puede ser revisar qué commits existen en muchas ramas que no se encuentran en la rama en la que se realiza el trabajo actualmente. -Git permite realizar esto utilizando el caracter `^` or `--not` antes de cualquier referencia de la cual no deseas ver los commits alcanzables. +La sintaxis de dos puntos es útil como una abreviatura; pero tal vez se desea especificar más de dos ramas para indicar la revisión, como puede ser revisar qué 'commits' existen en muchas ramas que no se encuentran en la rama en la que se realiza el trabajo actualmente. +Git permite realizar esto utilizando el caracter `^` o el comando `--not` antes de cualquier referencia de la cual no deseas ver los 'commits' alcanzables. [source,console] ---- @@ -316,7 +316,7 @@ $ git log refB --not refA ---- Esto es bueno porque con esta sintaxis se puede especificar más de dos referencias en una consulta, lo que no se puede hacer con la sintaxis de dos puntos. -Por ejemplo, si se quiere ver todos los commits que son alcanzables desde `refA` o `refB` pero no desde `refC`, se puede escribir lo siguiente: +Por ejemplo, si se quiere ver todos los 'commits' que son alcanzables desde `refA` o `refB` pero no desde `refC`, se puede escribir lo siguiente: [source,console] ---- @@ -324,13 +324,13 @@ $ git log refA refB ^refC $ git log refA refB --not refC ---- -Esto lo convierte en un sistema de consultas muy poderoso que debería ayudar a descubrir qué hay en sus ramas. +Esto lo convierte en un sistema de consultas muy poderoso que debería ayudar a descubrir qué hay en tus ramas. [[r_triple_dot]] ===== Tres puntos -La última sintaxis de selección de rangos es la de tres puntos, que especifica todos los commits que son alcanzables por alguna de dos referencias pero no por las dos al mismo tiempo. -Mire atrás al ejemplo de historial de commits en <>. +La última sintaxis de selección de rangos es la de tres puntos, que especifica todos los 'commits' que son alcanzables por alguna de dos referencias, pero no por las dos al mismo tiempo. +Mira atrás al ejemplo de historial de commits en <>. Si se quiere ver lo que está en `master` o `experiment` pero no en ambos, se puede utilizar [source,console] @@ -342,9 +342,9 @@ D C ---- -Nuevamente, esto entrega la salida normal del `log` pero muestra solo la información de esos cuatro commits, apareciendo en el tradicional ordenamiento por fecha de commit. +Nuevamente, esto entrega la salida normal del `log` pero muestra solo la información de esos cuatro 'commits', apareciendo en el tradicional ordenamiento por fecha de ``commit''. -Un cambio común para utilizar con el comando `log` en este caso es `--left-right`, el cual muestra en qué lado del rango se encuentra cada commit. +Un cambio común para utilizar con el comando `log`, en este caso, es `--left-right`, el cual muestra en qué lado del rango se encuentra cada ``commit''. Esto ayuda a hacer la información más útil: [source,console] @@ -356,4 +356,4 @@ $ git log --left-right master...experiment > C ---- -Con estas herramientas, se puede hacer saber más facilmente a Git qué commit o commits desea inspecionar. +Con estas herramientas, se puede hacer saber más facilmente a Git qué ``commit'' o 'commits' desea inspeccionar. diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index fc03274d..cefbb299 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -3,16 +3,16 @@ 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. +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 hechas 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. -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. +En esta sección, verás cómo complementar esas tareas tan útiles que harán a la confirmación de tu historia aparecer del modo en el cual quisiste compartirla. [[r_git_amend]] ==== Cambiando la última confirmación 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. +Comúnmente querrás hacer dos cosas en tu última confirmación: cambiar la confirmación del mensaje, o cambiar la parte instantánea que acabas de agregar sumando, cambiando y/o removiendo archivos. Si solamente quieres cambiar la confirmación del mensaje final, es muy sencillo: @@ -22,32 +22,32 @@ $ git commit --amend ---- Esto te envía al editor de texto, el cual tiene tu confirmación final, listo para modificarse en el mensaje. -Cuando guardes y cierres el editor, el editor escribe una nueva confirmación conteniendo el mensaje y lo con tu ultima confirmación. +Cuando guardes y cierres el editor, el editor escribe una nueva confirmación conteniendo el mensaje y lo asigna a tu última confirmación. -Si ya ha cambiado su última confirmación y luego quiere cambiar la instantánea que confirmo al agregar o cambiar archivos, esto es por que posiblemente olvidó agregar un archivo recién creado cuando se confirmó originalmente, el proceso trabaja prácticamente de la misma manera. -Tu manejas los cambios que quieras editando el archivo y oprimiendo `git add` en este o `git rm` a un archivo adjunto, y el subsecuente git commit --amend toma tu área de trabajo actual y la vuelve una instantánea para la nueva confirmación. +Si ya has cambiado tu última confirmación y luego quieres cambiar la instantánea que confirmaste al agregar o cambiar archivos, porque posiblemente olvidaste agregar un archivo recién creado cuando se confirmó originalmente, el proceso trabaja prácticamente de la misma manera. +Tu manejas los cambios que quieras editando el archivo y oprimiendo `git add` en éste o `git rm` a un archivo adjunto, y el subsecuente `git commit --amend` toma tu área de trabajo actual y la vuelve una instantánea para la nueva confirmación. Debes ser cuidadoso con esta técnica porque puedes modificar los cambios del SHA-1 de la confirmación -Es como un muy pequeño rebase – no necesitas modificar tu ultima confirmación si ya el haz puesto. +Es como un muy pequeño 'rebase' – no necesitas modificar tu última confirmación si ya lo has hecho. [[r_changing_multiple]] ==== 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. -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. +Git no tiene una herramienta para modificar la historia, pero puedes usar la herramienta de 'rebase' para rebasar ciertas series de confirmaciones en el HEAD en el que se basaron originalmente en lugar de moverlas 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 comando `-i` a `git rebase`. +De igual manera debes indicar que tan atrás quieres regresar para reescribir las confirmaciones escribiendo en el comando cuál confirmación quieres rebasar. -Por ejemplo, si quieres cambiar las confirmaciones de los tres últimos mensajes, o cualquiera de los mensajes de confirmación de ese grupo, proporcionas un argumento para lo `git rebase -i` que quieras modificar de tu ultima confirmación, el cual es `HEAD~2^` or `HEAD~3` . -Debería ser más fácil el recordar el ~3 porque estás tratando de editar las últimas tres confirmaciones; pero ten en mente que estás designando actualmente cuatro confirmaciones atrás, la parte del ultimo cometido que deseas editar: +Por ejemplo, si quieres cambiar las confirmaciones de los tres últimos mensajes, o cualquiera de los mensajes de confirmación de ese grupo, proporcionas un argumento para el `git rebase -i` que quieras modificar de tu última confirmación, el cual es `HEAD~2^` o `HEAD~3` . +Debería ser más fácil el recordar el ~3 porque estás tratando de editar las últimas tres confirmaciones; pero ten en mente que estás designando actualmente cuatro confirmaciones atrás, aparte del último cometido que deseas editar: [source,console] ---- $ git rebase -i HEAD~3 ---- -Recuerda de Nuevo es este es un comando de rebase – cualquier confirmación incluida en el rango de `HEAD~3..HEAD` será reescrita, aun si cambias el mensaje o no. +Recuerda de Nuevo que este es un comando de 'rebase' – cualquier confirmación incluida en el rango de `HEAD~3..HEAD` será reescrita, aún si cambias el mensaje o no. No incluyas cualquier confirmación que ya hayas enviado al servidor central – si lo haces esto confundirá a los demás desarrolladores proporcionando una versión alternativa del mismo cambio. Utilizar este comando te da una lista de las confirmaciones en tu editor de texto que se ve como este: @@ -77,7 +77,7 @@ pick a5f4a0d added cat-file # Note that empty commits are commented out ---- -Es importante el notar que estas confirmaciones son escuchadas en el orden contrario de la que tú normalmente las verías usando el comando de `log`. +Es importante el notar que estas confirmaciones son escuchadas en el orden contrario del que tú normalmente las verías usando el comando de `log`. Si utilizaras un comando de `log`, verías algo como esto. [source,console] @@ -88,14 +88,14 @@ a5f4a0d added cat-file 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. +Nótese que el orden está 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 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. -Por ejemplo, para modificar solamente la tercera confirmación del mensaje, cambiarias el archivo para que se viera algo así: +Por ejemplo, para modificar solamente la tercera confirmación del mensaje, cambiarías el archivo para que se viera algo así: [source,console] ---- @@ -142,7 +142,7 @@ Cada vez, Git se parará, permitiéndote modificar la confirmación y continuar ==== Reordenando Confirmaciones De igual manera puedes usar rebases interactivos para reordenar o remover confirmaciones enteramente. -Si quieres remover la ``added cat-file'' confirmación y cambiar el orden en el cual las otras dos confirmaciones son introducidas, puedes cambiar el rebase en el script de esto: +Si quieres remover la ``added cat-file'' confirmación y cambiar el orden en el cual las otras dos confirmaciones son introducidas, puedes cambiar el 'rebase' en el script de esto: [source,console] ---- @@ -160,14 +160,14 @@ 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 recordará 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]] ==== Unir confirmaciones -También es posible el tomar series de confirmaciones y unirlas todas en una sola confirmación con la herramienta interactiva de rebase. -El script pone instrucciones que en el mensaje de rebase: +También es posible el tomar series de confirmaciones y unirlas todas en una sola confirmación con la herramienta interactiva de 'rebase'. +El script pone las instrucciones en el mensaje de rebase: [source,console] ---- @@ -190,7 +190,7 @@ El script pone instrucciones que en el mensaje de rebase: ---- 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: +Entonces, si quieres convertir en una única confirmación estas tres confirmaciones, deberás hacer que el script se vea como esto: [source,console] ---- @@ -199,7 +199,7 @@ squash 310154e updated README formatting and added blame squash a5f4a0d added cat-file ---- -Cuando guardes te salgas del editor, Git aplicará a los tres el cambio y después te dirigirá en el editor para fusionar los tres mensajes de la confirmación: +Cuando guardes y salgas del editor, Git aplicará a los tres el cambio y después te dirigirá en el editor para fusionar los tres mensajes de la confirmación: [source,console] ---- @@ -220,10 +220,10 @@ Cuando guardes eso, tendrás una única confirmación que introducirá los cambi ==== 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. +Dividir una confirmación la deshace y después realiza etapas parciales 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'': +Puedes hacer eso en el script `rebase -i` cambiando la instrucción en la confirmación que quieres dividir a ``edit'': [source,console] ---- @@ -232,10 +232,10 @@ 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? -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: +¿Entonces, cuando el script te envíe 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 primera confirmación en tu lista, aplicando a la primera confirmación (`f7f3f6d`), 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 referidos. +Ahora puedes organizar y confirmar los archivos hasta que tengas varias confirmaciones y ejecutar `git rebase --continue` cuando hayas terminado: [source,console] ---- @@ -263,18 +263,18 @@ Una vez de Nuevo, esto cambia el SHA-1s de todas tus confirmaciones en tu lista, ==== La opción nuclear: filtrar-ramificar Existe otra opción en la parte de volver a escribir la historia que puedes usar si necesitas reescribir un gran número de confirmaciones de una manera que se puedan scriptear – de hecho, cambiar tu dirección de e-mail o remover cualquier archivo en las confirmaciones. -El comando es `filter-branch`, y este puede reescribir una gran cantidad de franjas de su historia, así que probablemente no lo deberías usar a menos que tu proyecto aún no sea público y otra persona no se haya basado en sus confirmaciones que estás a punto de reescribir. +El comando es `filter-branch`, y este puede reescribir una gran cantidad de franjas de tu historia, así que probablemente no lo deberías usar a menos que tu proyecto aún no sea público y otra persona no se haya basado en las confirmaciones que estás a punto de reescribir. 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 -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. +Esto ocurre comunmente. +Alguien accidentalmente confirma un gran número 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. -Para remover un archivo nombrado passwords.txt de tu historia complete puedes usar el `--tree-filter` option to `filter-branch`: +Para remover un archivo nombrado passwords.txt de tu historia complete puedes aplicar el comando `--tree-filter` a `filter-branch`: [source,console] ---- @@ -283,18 +283,18 @@ Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) Ref 'refs/heads/master' was rewritten ---- -El `--tree-filter` inicia el comando especifico después de cada revisión del proyecto y este entonces vuelve a confirmar los resultados. -En este caso, deberías remover el archivo llamado passwords.txt de cada instantánea, aun si existe o no. -si quieres remover todas las confirmaciones accidentales del respaldo del editor de archivos, puedes iniciar algo como el `git filter-branch --tree-filter 'rm -f *~' HEAD`. +El `--tree-filter` inicia el comando específico después de cada revisión del proyecto y éste entonces vuelve a confirmar los resultados. +En este caso, deberías remover el archivo llamado passwords.txt de cada instantánea, aún si existe o no. +Si quieres remover todas las confirmaciones accidentales del respaldo del editor de archivos, puedes iniciar algo como el `git filter-branch --tree-filter 'rm -f *~' HEAD`. -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. +Deberías ser capaz de ver la re-escripción de confirmaciones y estructuras de 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 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. ===== 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: +Suponiendo que has hecho una importación desde otro centro de Sistema de Control y tienes subdirecciones que no tienen ningún sentido (tronco, etiquetas, etc). . + Si quieres hacer que el subdirectorio `tronco` sea el nuevo proyecto de la raíz de cada confirmación, `filter-branch` te puede ayudar a hacer eso también: [source,console] ---- @@ -303,14 +303,14 @@ Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) Ref 'refs/heads/master' was rewritten ---- -Ahora la raíz de tu Nuevo proyecto es la que solía estar en el `tronco` subdirectorio cada vez. +Ahora la raíz de tu nuevo proyecto es la que solía estar en el subdirectorio `tronco` cada vez. Git automáticamente remueve confirmaciones que no afecten al subdirectorio. ===== Cambiar la dirección de e-mail globalmente -Otro caso comun es que olvides iniciar el git config para poner tu nombre tu dirección de e-mail antes de que hayas empezado a trabajar, o tal vez quieres abrir un proyecto en el trabajo y cambiar todo tu e-mail de trabajo por tu e-mail personal. -De cualquier caso, puedes cambiar la dirección de e-mail en multiples confirmaciones en un lote con `filter-branch` igual. -Necesitas ser cuidadoso de cambiar solo las direcciones de e-mail que son tuyas, de manera que debes usar `--commit-filter`: +Otro caso común es que olvides iniciar el `git config` para poner tu nombre y tu dirección de e-mail antes de que hayas empezado a trabajar, o tal vez quieres abrir un proyecto en el trabajo y cambiar tu e-mail de trabajo por tu e-mail personal. +En cualquier caso, puedes cambiar la dirección de e-mail de múltiples confirmaciones en un lote con `filter-branch` igual. +Necesitas ser cuidadoso de cambiar sólo las direcciones de e-mail que son tuyas, de manera que debes usar `--commit-filter`: [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. -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. +Esto va a través de la re-escripción de cada confirmación para tener tu nuva dirección. +Porque cada confirmación contiene el SHA-1 de sus padres, este comando cambia cada confirmación 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 6da85ba6..e49aafa6 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -2,15 +2,15 @@ === Buscando -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. +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 instantáneas almacenadas en su base de datos de forma rápida y fácil. Vamos a revisar algunas de ellas. [[r_git_grep]] ==== Git Grep -Git se envía con un comando llamado `grep` que le permite buscar fácilmente a través de cualquier árbol o directorio de trabajo con commit por una cadena o expresión regular. Para estos ejemplos, veremos el código fuente de Git. +Git se envía con un comando llamado `grep` que le permite buscar fácilmente a través de cualquier árbol o directorio de trabajo con 'commit' por una cadena o expresión regular. Para estos ejemplos, veremos el código fuente de Git. -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. +Por defecto, mirará a través de los archivos en su directorio de trabajo. Puedes pasar `-n` para imprimir los números de línea donde Git ha encontrado coincidencias. [source,console] ---- @@ -29,7 +29,7 @@ git-compat-util.h:723:#define gmtime_r git_gmtime_r 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`: +Por ejemplo, en lugar de la llamada anterior, puedes hacer que Git resuma el resultado simplemente mostrándote qué archivos coinciden y cuántas coincidencias hay en cada archivo con la opción `--count`: [source,console] ---- @@ -41,7 +41,7 @@ date.c:2 git-compat-util.h:2 ---- -Si quiere ver qué método o función piensa que ha encontrado una coincidencia, puede pasar `-p`: +Si quieres ver en qué método o función piensa Git que ha encontrado una coincidencia, puedes pasar `-p`: [source,console] ---- @@ -54,7 +54,7 @@ date.c: if (gmtime_r(&time, tm)) { Así que aquí podemos ver que se llama a `gmtime_r` en las funciones `match_multi_number` y `match_digit` en el archivo date.c. -También puede buscar combinaciones complejas de cadenas con el indicador `--and`, que asegura que múltiples coincidencias estén en la misma línea. Por ejemplo, busquemos cualquier línea que defina una constante con las cadenas ``LINK'' o ``BUF_MAX'' en ellas en la base del código de Git en una versión 1.8.0 anterior. +También puedes buscar combinaciones complejas de cadenas con el indicador `--and`, que asegura que múltiples coincidencias estén en la misma línea. Por ejemplo, busquemos cualquier línea que defina una constante con las cadenas ``LINK'' o ``BUF_MAX'' en ellas en la base del código de Git en una versión 1.8.0 anterior. Aquí también usaremos las opciones `--break` y `--heading` que ayudan a dividir el resultado en un formato más legible. @@ -87,9 +87,9 @@ El comando `git grep` tiene algunas ventajas sobre los comandos de búsqueda nor ==== Búsqueda de Registro de Git -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. +Quizás no estás buscando **dónde** existe un término, sino **cuándo** existió o se introdujo. El comando `git log` tiene varias herramientas potentes para encontrar 'commits' específicos 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 ac 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 a Git que sólo nos muestre los 'commits' que agregaron o eliminaron esa cadena con la opción `-S`. [source,console] ---- @@ -98,15 +98,15 @@ e01503b zlib: allow feeding more than 4GB in one go ef49a7a zlib: zlib can only process 4GB at a time ---- -Si miramos la diferencia de esos commits, podemos ver que en `ef49a7a` se introdujo la constante y en `e01503b` se modificó. +Si miramos la diferencia de esos 'commits', podemos ver que en `ef49a7a` se introdujo la constante y en `e01503b` se modificó. -Si necesita ser más específico, puede proporcionar una expresión regular para buscar con la opción `-G`. +Si necesitas ser más específico, puedes proporcionar una expresión regular para buscar con la opción `-G`. ===== Búsqueda de Registro de Línea -Otra búsqueda de registro bastante avanzada que es increíblemente útil es la búsqueda del historial de línea. Esta es una adición bastante reciente y no muy conocida, pero puede ser realmente útil. Se llama con la opción `-L` a `git log` y le mostrará el historial de una función o línea de código en su base de código. +Otra búsqueda de registro bastante avanzada que es increíblemente útil es la búsqueda del historial de línea. Esta es una adición bastante reciente y no muy conocida, pero puede ser realmente útil. Se llama con la opción `-L` a `git log` y te mostrará el historial de una función o línea de código en tu base de código. -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. +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 cuando se creó la función por primera vez. [source,console] ---- @@ -146,4 +146,4 @@ 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. +Si Git no puede encontrar la forma de relacionar una función o método en tu lenguaje de programación, también puedes 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ías darle un rango de líneas o un único número de línea y obtendrás el mismo tipo de salida. diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index 89b28bb9..5750c2f7 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -1,7 +1,7 @@ [[r_signing]] === Firmando tu trabajo -Git es criptográficamente seguro, pero no es a prueba de tontos. Si estás tomando trabajo de otros de internet y quieres verificar que los commits son realmente de fuentes seguras, Git tiene unas cuantas maneras de firmar y verificar utilizando GPG. +Git es criptográficamente seguro, pero no es a prueba de tontos. Si estás tomando trabajo de otros de Internet y quieres verificar que los 'commits' son realmente de fuentes seguras, Git tiene unas cuantas maneras de firmar y verificar utilizando GPG. ==== Introducción a GPG @@ -31,11 +31,11 @@ Una vez que tengas una llave privada para firmar, puedes configurar Git para usa git config --global user.signingkey 0A46826A ---- -Ahora Git usará tu llave por defecto para firmar tags y commits si tu quieres. +Ahora Git usará tu llave por defecto para firmar 'tags' y 'commits' si tu quieres. ==== Firmando Tags -Si tienes una llave GPG privada configurada, ahora puedes usarla para firmar tags. Todo lo que tienes que hacer es usar `-s` en lugar de `-a`: +Si tienes una llave GPG privada configurada, ahora puedes usarla para firmar 'tags'. Todo lo que tienes que hacer es usar `-s` en lugar de `-a`: [source,console] ---- @@ -46,7 +46,7 @@ user: "Ben Straub " 2048-bit RSA key, ID 800430EB, created 2014-05-04 ---- -Si ejecutas `git show` en ese tag, puedes ver tu firma GPG adjunta a él: +Si ejecutas `git show` en ese 'tag', puedes ver tu firma GPG adjunta a él: [source,console] -------- @@ -77,7 +77,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Verficando Tags -Para verificar un tag firmado, usa `git tag -v [nombre-de-tag]`. Este comando usa GPG para verificar la firma. Necesitas tener guardada la llave pública del usuario para que esto funcione de manera apropiada: +Para verificar un tag firmado, usa `git tag -v [nombre-de-tag]`. Este comando usa GPG para verificar la firma. Necesitas tener guardada la llave pública del usuario para que esto funcione de manera apropiada: [source,console] ---- @@ -108,7 +108,7 @@ error: could not verify the tag 'v1.4.2.1' [[r_signing_commits]] ==== Firmando Commits -En versiones más recientes de Git (v1.7.9 en adelante), ahora puedes firmar commits individuales. Si estás interesado en firmar commits directamente en lugar de solo los tags, todo lo que necesitas hacer es agregar un `-S` a tu comando `git commit`. +En versiones más recientes de Git (v1.7.9 en adelante), ahora puedes firmar 'commits' individuales. Si estás interesado en firmar 'commits' directamente en lugar de solo los 'tags', todo lo que necesitas hacer es agregar un `-S` a tu comando `git commit`. [source,console] ---- @@ -150,11 +150,11 @@ ca82a6d N Scott Chacon changed the version number a11bef0 N Scott Chacon first commit ---- -Aquí podemos ver que solo el último commit es firmado y válido y los commits previos no. +Aquí podemos ver que sólo el último 'commit' es firmado y válido y los 'commits' previos no. -En Git 1.8.3 y posteriores, "git merge" y "git pull" pueden ser configurados para inspeccionar y rechazar cualquier commit que no adjunte una firma GPG de confianza con el comando `--verify-signatures`. +En Git 1.8.3 y posteriores, "git merge" y "git pull" pueden ser configurados para inspeccionar y rechazar cualquier 'commit' que no adjunte una firma GPG de confianza con el comando `--verify-signatures`. -Si se usa esta opción cuando se fusiona una rama y esta contiene commits que no están firmados y son válidos, la fusión no funcionará. +Si se usa esta opción cuando se fusiona una rama y esta contiene 'commits' que no están firmados, aunque sean válidos, la fusión no funcionará. [source,console] ---- @@ -162,7 +162,7 @@ $ git merge --verify-signatures non-verify fatal: Commit ab06180 does not have a GPG signature. ---- -Si una fusión contiene solo commits válidos y firmados, el comando merge mostrará todas las firmas que ha revisado y después procederá con la fusión. +Si una fusión contiene solo 'commits' válidos y firmados, el comando `merge` mostrará todas las firmas que ha revisado y después procederá con la fusión. [source,console] ---- @@ -174,7 +174,7 @@ Fast-forward 1 file changed, 2 insertions(+) ---- -También se puede utilizar la opción `-S` junto con el mismo comando `git merge` para firmar el commit resultante. El siguiente ejemplo verifica que cada commit en la rama por ser fusionada esté firmado y también firma el commit resultado de la fusión. +También se puede utilizar la opción `-S` junto con el mismo comando `git merge` para firmar el 'commit' resultante. El siguiente ejemplo verifica que cada 'commit' en la rama por ser fusionada esté firmado y también firma el 'commit' resultado de la fusión. [source,console] ---- @@ -192,4 +192,4 @@ Merge made by the 'recursive' strategy. ==== Todos deben firmar -Firmar tags y commits es grandioso, pero si decides usar esto en tu flujo de trabajo normal, tendrás que asegurar que todos en el equipo entiendan cómo hacerlo. Si no, terminarás gastando mucho tiempo ayudando a las personas a descubrir cómo reescribir sus commits con versiones firmadas. Asegúrate de entender GPG y los beneficios de firmar cosas antes de adoptarlo como parte de tu flujo de trabajo normal. +Firmar 'tags' y 'commits' es grandioso, pero si decides usar esto en tu flujo de trabajo normal, tendrás que asegurarte que todos en el equipo entiendan cómo hacerlo. Si no, terminarás gastando mucho tiempo ayudando a las personas a descubrir cómo reescribir sus 'commits' con versiones firmadas. Asegúrate de entender GPG y los beneficios de firmar cosas antes de adoptarlo como parte de tu flujo de trabajo normal. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 2f566901..6a87998d 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -2,14 +2,14 @@ === Guardado rápido y Limpieza Muchas veces, cuando has estado trabajando en una parte de tu proyecto, las cosas se encuentran desordenadas y quieres cambiar de ramas por un momento para trabajar en algo más. -El problema es que no quieres hacer un commit de un trabajo que va por la mitad, así puedes volver a ese punto más tarde. +El problema es que no quieres hacer un ``commit'' de un trabajo que va por la mitad, así puedes volver a ese punto más tarde. La respuesta a ese problema es el comando `git stash`. El guardado rápido toma el desorden de tu directorio de trabajo – que es, tus archivos controlados por la versión modificados y cambios almacenados – y lo guarda en un saco de cambios sin terminar que puedes volver a usar en cualquier momento. ==== Guardando rápido tu trabajo -Para demostrar, irás a tu proyecto y empezarás a trabajar en un par de archivos y posiblemente en tu etapa uno de cambios. +Para demostrarlo, irás a tu proyecto y empezarás a trabajar en un par de archivos y posiblemente en tu etapa uno de cambios. Si ejecutas `git status`, puedes ver tu estado sucio: [source,console] @@ -27,7 +27,7 @@ Changes not staged for commit: modified: lib/simplegit.rb ---- -Ahora quieres cambiar de ramas, pero no quieres hacer commit a lo que has estado trabajando todavía; así que le harás un guardado rápido a los cambios. +Ahora quieres cambiar de rama, pero no quieres hacer ``commit'', todavía, a lo que has estado trabajando; así que le harás un guardado rápido a los cambios. Para poner un nuevo guardado rápido en tus archivos, ejecuta `git stash` o `git stash save`: [source,console] @@ -48,7 +48,7 @@ $ git status nothing to commit, working directory clean ---- -En este punto, puedes fácilmente cambiar de ramas y hacer trabajos en otro lugar; tus cambios están guardados en tus archivos. +En este punto, puedes fácilmente cambiar de ramas y hacer trabajos en otro lugar; tus cambios están guardados en tus archivos. Para ver qué guardados rápidos has almacenado, puedes usar `git stash list`: [source,console] @@ -59,10 +59,10 @@ stash@{1}: WIP on master: c264051 Revert "added file_size" stash@{2}: WIP on master: 21d80a5 added number to log ---- -In this case, two stashes were done previously, so you have access to three different stashed works. -You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. +En este caso, dos guardados fueron hechos previamente, así que tienes tres diferentes trabajos guardados. +Puedes volver a aplicar el que acabas de guardar utilizando el comando que se muestra en la salida de ayuda del comando original: `git stash apply`. Si quieres hacer entrada a uno de los guardados rápidos anteriores, puedes especificarlo poniendo su nombre de esta manera: `git stash apply stash@{2}`. -Si no especificas un guardado, el Git adopta el guardado más reciente e intenta hacerle entrada: +Si no especificas un guardado, Git adopta el guardado más reciente e intenta hacerle entrada: [source,console] ---- @@ -76,14 +76,14 @@ $ git stash apply # ---- -Puedes ver que el Git remodifica los archivos que revertiste cuando hiciste el guardado rápido. -En este caso, tenías un directorio de trabajo despejado cuando intentaste hacer entrada al guardado, e intentaste hacerle entrada en la misma rama en la que la guardaste; pero tener un directorio de trabajo despejado y usarlo en la misma rama no es necesario para hacerle entrada a un guardado con éxito. +Puedes ver que Git remodifica los archivos que revertiste cuando hiciste el guardado rápido. +En este caso, tenías un directorio de trabajo despejado cuando intentaste hacer entrada al guardado, e intentaste hacerle entrada en la misma rama en la que lo guardaste; pero tener un directorio de trabajo despejado y usarlo en la misma rama no es necesario para hacerle entrada a un guardado con éxito. Puedes almacenar un guardado en una rama, cambiar a otra rama luego, e intentar volver a hacerle entrada a los cambios. También puedes tener archivos modificados y sin aplicar en tu directorio de trabajo cuando des entrada a un guardado – Git te da conflictos de cambinación si algo ya no se usa de manera limpia. -Los cambios a tus archivos fueron reaplicados, pero el archivo que tu guardaste antes no fue realmacenado. -Para hacer eso, tienes que ejecuar el comando `git stash apply` con una opción de `--index` para decirle al comando que intente reaplicar los cambios almacenados. -Si en cambio lo hubieras ejecutado, lo habrías vuelto a tener en su posición original: +Los cambios a tus archivos fueron reaplicados, pero el archivo que tu guardaste antes no fue realmacenado. +Para hacer eso, tienes que ejecuar el comando `git stash apply` con una opción de `--index` para decirle al comando que intente reaplicar los cambios almacenados. +Si anteriormente lo hubieras ejecutado, lo habrías vuelto a tener en su posición original: [source,console] ---- @@ -118,9 +118,9 @@ También puedes ejecutar `git stash pop` para hacer entrada al guardado y luego ==== Guardado rápido creativo -Hay algunas pocas variantes de guardado rápido que pueden ser útiles también. La primera opción que es muy popular es la opción `--keep-index` para el comando `stash save`. Esto le dice a Git que no guarde nada que tú ya hayas almacenado con el comando `git add`. +Hay algunas pocas variantes de guardado rápido que pueden ser útiles también. La primera opción que es muy popular es `--keep-index` para el comando `stash save`. Esto le dice a Git que no guarde nada que tú ya hayas almacenado con el comando `git add`. -Esto puede ser útil de verdad si has hecho un buen número de cambios, pero sólo quiere aplicar permanentemente algunos de ellos y luego regresar al resto de cambios en una siguient ocasión. +Esto puede ser útil de verdad si has hecho un buen número de cambios, pero sólo quieres aplicar permanentemente algunos de ellos y luego regresar al resto de cambios en una siguient ocasión. [source,console] ---- @@ -136,7 +136,7 @@ $ git status -s M index.html ---- -Otra cosa común que puede que quieras hacer con tus guardados es hacer un guardado rápido de los archivos que no están bajo control de la versión al igual que con los que lo están. Por defecto, git stash` sólamente guardará archivos que ya están en el índice. Si especificas `--include-untracked` o `-u`, el Git tambien hará un guardado rápido de cualquier archivo que no esté bajo control de la versión que hayas creado. +Otra cosa común que puede que quieras hacer con tus guardados es hacer un guardado rápido de los archivos que no están bajo control de la versión al igual que con los que lo están. Por defecto, `git stash` solamente guardará archivos que ya están en el índice. Si especificas `--include-untracked` o `-u`, Git también hará un guardado rápido de cualquier archivo que no esté bajo control de la versión que hayas creado. [source,console] ---- @@ -153,7 +153,7 @@ $ git status -s $ ---- -Finalmente, si especificas el flag `--patch`, el Git no hará guardado rápido de todo lo que es modificado, pero, en su lugar, te recordará cuales de los cambios te gustaría guardar y cuales te gustaría mantener en tu trabajo directamente. +Finalmente, si especificas la flag `--patch`, Git no hará guardado rápido de todo lo que es modificado, pero, en su lugar, te recordará cuales de los cambios te gustaría guardar y cuales te gustaría mantener en tu trabajo directamente. [source,console] ---- @@ -181,9 +181,9 @@ Saved working directory and index state WIP on master: 1b65b17 added the index f ==== Creando una Rama desde un Guardado Rápido -Si haces guardado rápido de algo de trabajo, déjalo ahí por un rato, y continúa en la rama de la cual hiciste guardado rápido de tu trabajo, puede que tengas problemas rehaciendo entrada al trabajo. +Si haces guardado rápido de algo de trabajo, lo dejas ahí por un rato y continúas en la rama de la cual hiciste guardado rápido de tu trabajo, puede que tengas problemas rehaciendo la entrada al trabajo. Si la entrada intenta modificar un archivo que desde entonces has modificado, tendrás un conflicto de combinación y tendrás que intentar resolverlo. -Si quieres una forma más fácil de probar los cambios guardados de nuevo, puedes ejecutar `git stash branch`, el cual crea una nueva rama para ti, verifica el commit en el que estabas cuando hiciste guardado rápido de tu trabajo, recrea tu trabajo allí, y luego arroja el guardado rápido si la entrada se realiza con éxito: +Si quieres una forma más fácil de probar los cambios guardados de nuevo, puedes ejecutar `git stash branch`, el cual crea una nueva rama para ti, verifica el ``commit'' en el que estabas cuando hiciste guardado rápido de tu trabajo, recrea tu trabajo allí, y luego arroja el guardado rápido si la entrada se realiza con éxito: [source,console] ---- @@ -203,20 +203,20 @@ Switched to a new branch "testchanges" Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) ---- -Este es un buen método rápido para recuperar rápidamente trabajos guardados y trabajar en una nueva rama. +Este es un buen método rápido para recuperar trabajos guardados y trabajar en una nueva rama. [[r_git_clean]] ==== Limpiando tu Directorio de Trabajo -Finalmente, puede que no quieras hacer guardado rápido de algo de trabajo o de archivos en tu directorio de trabajo, pero quieres desaserte de ellos. El comando `git clean` hará esto por ti. +Finalmente, puede que no quieras hacer guardado rápido de algo de trabajo o de archivos en tu directorio de trabajo, pero quieres deshacerte de ellos. El comando `git clean` hará esto por ti. -Algunas razones comunes para esto pueden ser para remover archivos cruft que han sido generados por herramientas de combinación o externas o para eliminar viejos archivos de versión con el fin de ejecutar una versión limpia. +Algunas razones comunes para esto pueden ser: remover archivos cruft que han sido generados por herramientas de combinación o externas, o para eliminar viejos archivos de versión con el fin de ejecutar una versión limpia. Querrás ser más bien delicado con este comando, ya que está diseñado para eliminar archivos de tu directorio de trabajo que no están siendo tomados en cuenta. Si cambias de opinión, muchas veces no hay restauración para el contenido de esos archivos. Una opción más segura es ejecutar `git stash --all` para eliminar todo, pero lo almacena en un guardado. -Asumiendo que quieres eliminar los archivos cruft o limpiar tu directorio de trabajo, puedes hacerlo con `git clean`. Para remover los archivos que no están bajo el control de la versión en tu directorio de trabajo, puedes ejecutar `git clean -f -d`, el cual remueve cualquier archivo y también cualquier subdirectorio que se vuelva vacío como resultado. El `-f` significa 'fuerza' o “realmente hace esto”. +Asumiendo que quieres eliminar los archivos cruft o limpiar tu directorio de trabajo, puedes hacerlo con `git clean`. Para remover los archivos que no están bajo el control de la versión en tu directorio de trabajo, puedes ejecutar `git clean -f -d`, el cual remueve cualquier archivo y también cualquier subdirectorio que se vuelva vacío como resultado. El `-f` significa 'fuerza' o “realmente haz esto”. -Si alguna vez quieres ver que haría, puedes ejecutar el comando con la opción `-n` que significa ``haz un arranque en seco y dime que habías eliminado ''. +Si alguna vez quieres ver que haría, puedes ejecutar el comando con la opción `-n` que significa ``haz un arranque en seco y dime que habrías eliminado ''. [source,console] ---- @@ -225,7 +225,7 @@ Would remove test.o Would remove tmp/ ---- -Por defecto, el comando `git clean` solo removerá archivos que no sean controlados que no sean ignorados. Cualquier archivo que empareje en patrón en tu `.gitignore` u otros archivos ignorados no serán removidos. Si quieres eliminar esos archivos también, como eliminar todos `.o` files generados por la versión, así puedes hacer una versión completamente limpia, puedes añadir un `-x` al comando en limpio. +Por defecto, el comando `git clean` sólo removerá archivos que no sean controlados y que no sean ignorados. Cualquier archivo que empareje en patrón en tu `.gitignore` u otros archivos ignorados no serán removidos. Si quieres eliminar esos archivos también, como eliminar todos los `.o` generados por la versión, así puedes hacer una versión completamente limpia, puedes añadir un `-x` al comando. [source,console] ---- @@ -244,7 +244,7 @@ Would remove test.o Would remove tmp/ ---- -Si no sabes lo que el comando `git clean` va a hacer, siempre ejecútalo con un `-n` primero para estar seguro antes de cambiar el `-n` a `-f`y hacerlo de verdad. La otra forma en la que puedes ser cuidadoso con el proceso es ejecutarlo con el `-i` o con la flag ``interactive''. +Si no sabes lo que el comando `git clean` va a hacer, siempre ejecútalo con un `-n` primero para estar seguro antes de cambiar el `-n` a `-f` y hacerlo de verdad. La otra forma en la que puedes ser cuidadoso con el proceso es ejecutarlo con el `-i` o con la flag ``interactive''. Esto ejecutará el comando en limpio en un modo interactivo. @@ -259,4 +259,4 @@ Would remove the following items: What now> ---- -De esta forma puedes decidir por cada archivo individualmente o especificar los terminos para la eliminación de forma interactiva. +De esta forma puedes decidir por cada archivo individualmente o especificar los términos para la eliminación de forma interactiva. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 2fb535db..1daa0473 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -2,7 +2,7 @@ === Submódulos A menudo ocurre que mientras trabaja en un proyecto, necesita usar otro proyecto desde adentro. -Tal vez se trate de una biblioteca desarrollada por un tercero o que ustéd está desarrollando por separado y que se utiliza en múltiples proyectos principales. +Tal vez se trate de una biblioteca desarrollada por un tercero, o que usted está desarrollando por separado y que se utiliza en múltiples proyectos principales. Un problema común surge en estos escenarios: desea poder tratar los dos proyectos como separados y aún así poder usar uno desde el otro. Aquí hay un ejemplo. @@ -10,11 +10,11 @@ Supongamos que está desarrollando un sitio web y creando feeds Atom. En lugar de escribir su propio código de generación de Atom, decide usar una biblioteca. Es probable que tenga que incluir este código de una biblioteca compartida, como una instalación CPAN o Ruby gem, o copiar el código fuente en su propio árbol de proyectos. El problema con la inclusión de la biblioteca es que es difícil personalizar la biblioteca de alguna manera y, a menudo, es más difícil de implementar, porque debe asegurarse de que cada cliente tenga esa biblioteca disponible. -El problema con el envío del código a su propio proyecto es que cualquier cambio personalizado que realice es difícil de fusionar cuando estén disponibles los cambios de upstream. +El problema con el envío del código a su propio proyecto es que cualquier cambio personalizado que realice es difícil de fusionar cuando estén disponibles los cambios de 'upstream'. Git aborda este problema utilizando submódulos. Los submódulos le permiten mantener un repositorio de Git como un subdirectorio de otro repositorio de Git. -Esto le permite clonar otro repositorio en su proyecto y mantener sus commits separados. +Esto le permite clonar otro repositorio en su proyecto y mantener sus 'commits' separados. [[r_starting_submodules]] ==== Comenzando con los Submódulos @@ -87,9 +87,9 @@ index 0000000..c3f01dc ---- Aunque `DbConnector` es un subdirectorio en su directorio de trabajo, Git lo ve como un submódulo y no rastrea su contenido cuando usted no está en ese directorio. -En cambio, Git lo ve como un commit particular de ese repositorio. +Sin embargo, Git sí lo ve como un ``commit'' particular de ese repositorio. -Si quieres una mejor salida de diff, puedes pasar la opción `--submodule` a `git diff`. +Si quiere una mejor salida de diff, puede pasar la opción `--submodule` a `git diff`. [source,console] ---- @@ -106,7 +106,7 @@ index 0000000..71fc376 Submodule DbConnector 0000000...c3f01dc (new submodule) ---- -Cuando hace commit, ve algo como esto: +Cuando hace ``commit'', ve algo como esto: [source,console] ---- @@ -153,7 +153,7 @@ $ ---- El directorio `DbConnector` está ahí, pero está vacío. -Debe ejecutar dos comandos: `git submodule init` para inicializar su archivo de configuración local, y `git submodule update` para buscar todos los datos de ese proyecto y verifique la commit adecuada que figura en su superproyecto: +Debe ejecutar dos comandos: `git submodule init` para inicializar su archivo de configuración local, y `git submodule update` para buscar todos los datos de ese proyecto y que verifique el ``commit'' adecuado que figura en su superproyecto: [source,console] ---- @@ -169,7 +169,7 @@ Checking connectivity... done. Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc' ---- -Ahora su subdirectorio `DbConnector` está en el estado exacto en el que estaba cuando hizo commit antes. +Ahora su subdirectorio `DbConnector` está en el estado exacto en el que estaba cuando hizo ``commit'' antes. Sin embargo, hay otra manera de hacer esto que es un poco más simple. Si pasa `--recursive` al comando `git clone`, se inicializará y actualizará automáticamente cada submódulo en el repositorio. @@ -198,9 +198,9 @@ Ahora tenemos una copia de un proyecto con submódulos y colaboraremos con nuest ===== Llegada de los Cambios de Upstream -El modelo más simple de usar submódulos en un proyecto sería si simplemente consumiera un subproyecto y quisiera obtener actualizaciones de él de vez en cuando, pero en realidad no estuviera modificando nada en el proceso de pago. Veamos un ejemplo simple allí. +El modelo más simple de usar submódulos en un proyecto sería si simplemente consumiera un subproyecto y quisiera obtener actualizaciones de él de vez en cuando, pero en realidad no estuviera modificando nada en el proceso. Veamos un ejemplo simple de esto. -Si desea buscar trabajo nuevo en un submódulo, puede acceder al directorio y ejecutar `git fetch` y `git merge` en la rama upstream para actualizar el código local. +Si desea buscar trabajo nuevo en un submódulo, puede acceder al directorio y ejecutar `git fetch` y `git merge` en la rama 'upstream' para actualizar el código local. [source,console] ---- @@ -215,7 +215,7 @@ Fast-forward 2 files changed, 2 insertions(+) ---- -Ahora, si vuelve al proyecto principal y ejecuta `git diff --submodule` puede ver que el submódulo se actualizó y obtener una lista de commits que se le agregaron. Si no desea escribir `--submodule` cada vez que ejecuta `git diff`, puede establecerlo como el formato predeterminado configurando el valor de configuración `diff.submodule` en ``log''. +Ahora, si vuelve al proyecto principal y ejecuta `git diff --submodule` puede ver que el submódulo se actualizó y obtener una lista de 'commits' que se le agregaron. Si no desea escribir `--submodule` cada vez que ejecuta `git diff`, puede establecerlo como el formato predeterminado configurando el valor de configuración `diff.submodule` en ``log''. [source,console] ---- @@ -226,9 +226,9 @@ Submodule DbConnector c3f01dc..d0354fc: > better connection routine ---- -Si hace commit en este punto, bloqueará el submódulo para que tenga el nuevo código cuando otras personas lo actualicen. +Si hace ``commit'' en este punto, bloqueará el submódulo para que tenga el nuevo código cuando otras personas lo actualicen. -También hay una forma más sencilla de hacer esto si prefiere no buscar y fusionar manualmente en el subdirectorio. Si ejecuta `git submodule update --remote`, Git irá a sus submódulos y buscará y actualizará por usted. +También hay una forma más sencilla de hacer esto si prefiere no buscar y fusionar manualmente en el subdirectorio. Si ejecuta `git submodule update --remote`, Git irá a sus submódulos y buscará y actualizará todo por usted. [source,console] ---- @@ -242,7 +242,7 @@ From https://github.com/chaconinc/DbConnector Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0644' ---- -Este comando asumirá de forma predeterminada que desea actualizar el pago a la rama `master` del repositorio de submódulos. Sin embargo, puede establecer esto en algo diferente si lo desea. Por ejemplo, si desea que el submódulo DbConnector rastree la rama ``stable'' del repositorio, puede configurarlo en su archivo `.gitmodules` (para que todos los demás también lo rastreen), o simplemente en su archivo `.git/config` local. Vamos a configurarlo en el archivo `.gitmodules`: +Este comando asumirá de forma predeterminada que desea actualizar la rama `master` del repositorio de submódulos. Sin embargo, puede establecer esto en algo diferente si lo desea. Por ejemplo, si desea que el submódulo DbConnector rastree la rama ``stable'' del repositorio, puede configurarlo en su archivo `.gitmodules` (para que todos los demás también lo rastreen), o simplemente en su archivo `.git/config` local. Vamos a configurarlo en el archivo `.gitmodules`: [source,console] ---- @@ -301,7 +301,7 @@ Submodules changed but not updated: > catch non-null terminated lines ---- -En este punto, si ejecuta `git diff` podemos ver que hemos modificado nuestro archivo `.gitmodules` y también que hay un número de commits que hemos eliminado y estamos listos para hacer commit a nuestro proyecto de submódulo. +En este punto, si ejecuta `git diff` podemos ver que hemos modificado nuestro archivo `.gitmodules` y también que hay un número de 'commits' que hemos eliminado y estamos listos para hacer ``commit'' a nuestro proyecto de submódulo. [source,console] ---- @@ -323,7 +323,7 @@ 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`. +Esto es muy bueno ya que podemos ver el registro de los 'commits' a los que estamos a punto de hacer ``commit'' en nuestro submódulo. Una vez hecho el ``commit'', puede ver esta información también cuando ejecuta `git log -p`. [source,console] ---- @@ -354,15 +354,15 @@ Git intentará por defecto actualizar **todos** sus submódulos cuando ejecute ` ===== Trabajando en un Submódulo -Es bastante probable que si está utilizando submódulos, lo esté haciendo porque realmente desea trabajar en el código dentro del submódulo al mismo tiempo que está trabajando en el código dentro del proyecto principal (o en varios submódulos). . De lo contrario, probablemente usaría un sistema de administración de dependencias más simple (como Maven o Rubygems). +Es bastante probable que si está utilizando submódulos, lo esté haciendo porque realmente desea trabajar en el código dentro del submódulo al mismo tiempo que está trabajando en el código dentro del proyecto principal (o en varios submódulos). De lo contrario, probablemente usaría un sistema de administración de dependencias más simple (como Maven o Rubygems). -Así que ahora veamos un ejemplo de cómo hacer cambios en el submódulo al mismo tiempo que el proyecto principal y de hacer commit y publicar esos cambios al mismo tiempo. +Así que ahora veamos un ejemplo de cómo hacer cambios en el submódulo al mismo tiempo que al proyecto principal y de hacer ``commit'' y publicar esos cambios conjuntamente. Hasta ahora, cuando ejecutamos el comando `git submodule update` para obtener cambios de los repositorios de submódulos, Git obtendría los cambios y actualizaría los archivos en el subdirectorio, pero deja el sub-repositorio en lo que se llama un estado ``detached HEAD''. Esto significa que no hay una rama de trabajo local (como ``master'', por ejemplo) que rastrea los cambios. Por lo tanto, los cambios que realice no serán rastreados correctamente. 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. +Primero que todo, vayamos a nuestro directorio de submódulos y verifiquemos una rama. [source,console] ---- @@ -401,7 +401,7 @@ $ git commit -am 'unicode support' 1 file changed, 1 insertion(+) ---- -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. +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] @@ -412,7 +412,7 @@ Applying: unicode support Submodule path 'DbConnector': rebased into '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94' ---- -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. +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] @@ -423,7 +423,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. +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] @@ -442,7 +442,7 @@ Aborting Unable to checkout 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector' ---- -Si realizó cambios que entran en conflicto con algo cambiado en upstream, Git le informará cuándo ejecutar la actualización. +Si realizó cambios que entran en conflicto con algo cambiado en 'upstream', Git le informará cuándo ejecutar la actualización. [source,console] @@ -476,9 +476,9 @@ Submodule DbConnector c87d55d..82d2ad3: > add new option for conn pooling ---- -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. +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. +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'' u ``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] @@ -528,11 +528,11 @@ Como puede ver allí, Git entró en el módulo DbConnector y lo empujó antes de ===== Fusionando Cambios de Submódulo -Si cambia una referencia de submódulo al mismo tiempo que otra persona, puede tener algunos problemas. Es decir, si los historiales de los submódulos han divergido y les han hecho commit a ramas divergentes en un súper proyecto, puede tomar un poco de trabajo en arreglar. +Si cambia una referencia de submódulo al mismo tiempo que otra persona, puede tener algunos problemas. Es decir, si los historiales de los submódulos han divergido y les han hecho ``commit'' a ramas divergentes en un súper proyecto, puede tomar un poco de trabajo arreglarlo. -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. +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 funcionará 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í: +Sin embargo, Git no intentará siquiera una fusión trivial para usted. Si los 'commits' del submódulo divergen y necesitan fusionarse, obtendrá algo que se ve así: [source,console] @@ -551,9 +551,9 @@ CONFLICT (submodule): Merge conflict in DbConnector 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. +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 lo explicaremos 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. +Para resolver el problema, debe averiguar en qué estado debería estar el submódulo. Curiosamente, Git no le da demasiada información para ayudarle 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 los 'commits' registrados en ambas ramas que estaba intentando fusionar. [source,console] ---- @@ -564,9 +564,9 @@ index eb41d76,c771610..0000000 +++ b/DbConnector ---- -Entonces, en este caso, `eb41d76` es la commit en nuestro submódulo que *nosotros* teníamos y `c771610` es la commit que tenía upstream. Si vamos a nuestro directorio de submódulos, ya debería estar en `eb41d76` ya que la fusión no lo habría tocado. Si por alguna razón no es así, simplemente puede crear y verificar una rama que lo señale. +Entonces, en este caso, `eb41d76` es el ``commit' en nuestro submódulo que *nosotros* teníamos y `c771610` es el ``commit'' que tenía 'upstream'. Si vamos a nuestro directorio de submódulos, ya debería estar en `eb41d76` ya que la fusión no lo habría tocado. Si por alguna razón no es así, simplemente puede crear y verificar una rama que lo señale. -Lo que es importante es el SHA-1 de la commit del otro lado. Esto es lo que tendrás que fusionar y resolver. Puedes simplemente probar la fusión con el SHA-1 directamente, o puedes crear una rama para él y luego intentar fusionar eso. Sugeriríamos este último, aunque sea para hacer un mejor mensaje de commit de fusión. +Lo que es importante es el SHA-1 del ``commit'' del otro lado. Esto es lo que tendrá que fusionar y resolver. Puede simplemente probar la fusión con el SHA-1 directamente, o puede crear una rama para él y luego intentar fusionar eso. Sugeriríamos esto último, aunque sea para poder hacer un mejor mensaje de ``commit'' de fusión. Por lo tanto, accederemos a nuestro directorio de submódulos, crearemos una rama basada en ese segundo SHA-1 de `git diff` y fusionaremos manualmente. @@ -585,7 +585,7 @@ Recorded preimage for 'src/main.c' Automatic merge failed; fix conflicts and then commit the result. ---- -Aquí tenemos un conflicto de fusión real, por lo que si resolvemos eso y le hacemos commit, podemos simplemente actualizar el proyecto principal con el resultado. +Aquí tenemos un conflicto de fusión real, por lo que si resolvemos eso y le hacemos ``commit'', podemos simplemente actualizar el proyecto principal con el resultado. [source,console] ---- @@ -620,11 +620,11 @@ $ git commit -m "Merge Tom's Changes" <5> Puede ser un poco confuso, pero realmente no es muy difícil. Curiosamente, hay otro caso que maneja Git. -Si existe un commit de fusión en el directorio del submódulo que contiene **ambos** commits en su historial, Git lo sugerirá como posible solución. Se ve que en algún punto del proyecto del submódulo, alguien fusionó las ramas que contienen estos dos commits, así que tal vez querrá esa. +Si existe un ``commit'' de fusión en el directorio del submódulo que contiene **ambos** 'commits' en su historial, Git lo sugerirá como posible solución. Se ve que en algún punto del proyecto del submódulo, alguien fusionó las ramas que contienen estos dos 'commits', así que tal vez querrá esa. Esta es la razón por la cual el mensaje de error de antes era ``fusionar los siguientes commits no encontrado'', porque no podía hacer *esto*. Es confuso porque ¿quién esperaría que **intentara** hacer esto? -Si encuentra una única commit de fusión aceptable, verá algo como esto: +Si encuentra un único commit de fusión aceptable, verá algo como esto: [source,console] ---- @@ -643,7 +643,7 @@ CONFLICT (submodule): Merge conflict in DbConnector Automatic merge failed; fix conflicts and then commit the result. ---- -Lo que está sugiriendo que haga es actualizar el índice como si hubiera ejecutado `git add`, que borra el conflicto y luego haga commit. Sin embargo, probablemente no debería hacer esto. También puede acceder fácilmente al directorio de submódulos, ver cuál es la diferencia, avanzar rápidamente a esta commit, probarla correctamente y luego hacerle commit. +Lo que está sugiriendo que haga es actualizar el índice como si hubiera ejecutado `git add`, que borra el conflicto y luego haga ``commit''. Sin embargo, probablemente no debería hacer esto. También puede acceder fácilmente al directorio de submódulos, ver cuál es la diferencia, avanzar rápidamente a este ``commit'', probarlo correctamente y luego hacerle ``commit''. [source,console] ---- @@ -660,13 +660,13 @@ $ git commit -am 'Fast forwarded to a common submodule child' Esto logra lo mismo, pero al menos de esta manera puede verificar que funcione y que tenga el código en el directorio de su submódulo cuando haya terminado. -==== Consejos de Cubmódulo +==== Consejos de Submódulo Hay algunas cosas que puede hacer para facilitar el trabajo con los submódulos. ===== Submódulo Foreach -Hay un comando del submódulo `foreach` para ejecutar algún comando arbitrario en cada submódulo. Esto puede ser realmente útil si tiene un número de submódulos en el mismo proyecto. +Hay un comando de submódulo `foreach` para ejecutar algún comando arbitrario en cada submódulo. Esto puede ser realmente útil si tiene un varios submódulos en el mismo proyecto. Por ejemplo, digamos que queremos comenzar una nueva característica o hacer una corrección de errores y tenemos trabajo sucediendo en varios submódulos. Podemos esconder fácilmente todo el trabajo en todos nuestros submódulos. @@ -691,7 +691,8 @@ Entering 'DbConnector' Switched to a new branch 'featureA' ---- -Entiende la idea. Una cosa realmente útil que puede hacer es producir una buena diff unificada de lo que ha cambiado en su proyecto principal y todos sus subproyectos también. +¿Entiende la idea? + Una cosa realmente útil que puede hacer es producir una buena 'diff unificada' de lo que ha cambiado en su proyecto principal y todos sus subproyectos también. [source,console] ---- @@ -729,7 +730,7 @@ index 1aaefb6..5297645 100644 struct strbuf out = STRBUF_INIT; ---- -Aquí podemos ver que estamos definiendo una función en un submódulo y llamándola en el proyecto principal. Obviamente, este es un ejemplo simplificado, pero con suerte le da una idea de cómo esto puede ser útil. +Aquí podemos ver que estamos definiendo una función en un submódulo y llamándola en el proyecto principal. Obviamente, este es un ejemplo simplificado, pero con suerte le dará una idea de cómo esto puede ser útil. ===== Alias Útiles @@ -855,6 +856,6 @@ Switched to branch 'master' Luego, cuando vuelve, obtiene un directorio `CryptoLibrary` vacío por alguna razón y `git submodule update` tampoco puede arreglarlo. Es posible que deba acceder al directorio de su submódulo y ejecutar un `git checkout .` para recuperar todos sus archivos. Puede ejecutar esto en un script `submodule foreach` para ejecutarlo en múltiples submódulos. -Es importante tener en cuenta que los submódulos de estos días mantienen todos sus datos de Git en el directorio `.git` del proyecto superior, por lo que a diferencia de muchas versiones anteriores de Git, la destrucción de un directorio de submódulos no perderá ningunas ramas o commits que tengas. +Es importante tener en cuenta que los submódulos de estos días mantienen todos sus datos de Git en el directorio `.git` del proyecto superior, por lo que a diferencia de muchas versiones anteriores de Git, la destrucción de un directorio de submódulos no perderá ninguna rama o ``commit'' que tenga. -Con estas herramientas, los submódulos pueden ser un método bastante simple y efectivo para desarrollar en varios proyectos relacionados pero aún separados simultáneamente. +Con estas herramientas, los submódulos pueden ser un método bastante simple y efectivo para desarrollar en varios proyectos relacionados pero separados simultáneamente. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 90e78177..d9c2dd01 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -8,7 +8,7 @@ Cuando especifica una convergencia de subárbol, Git suele ser lo suficientement Veremos un ejemplo donde se añade un proyecto separado a un proyecto existente y luego se converge el código del segundo dentro de un subdirectorio del primero. Primero, añadiremos la aplicación Rack a nuestro proyecto. -Añadiremos el proyecto Rack como referencia remota en nuestro propio proyecto y luego lo colocaremos en su propio branch: +Añadiremos el proyecto Rack como referencia remota en nuestro propio proyecto y luego lo colocaremos en su propia branch: [source,console] ---- @@ -44,21 +44,21 @@ $ ls README ---- -Este concepto es algo extraño. No todos los branchs en su repositorio tendrán que ser branchs del mismo proyecto como tal. No es común, porque rara vez es de ayuda, pero es fácil que los branchs contengan historias completamente diferentes. +Este concepto es algo extraño. No todas las 'branchs' en su repositorio tendrán que ser 'branchs' del mismo proyecto como tal. No es común, porque rara vez es de ayuda, pero es fácil que los 'branchs' contengan historias completamente diferentes. En este caso, queremos integrar el proyecto Rack a nuestro proyecto `master` como un subdirectorio. Podemos hacer eso en Git con `git read-tree`. -Aprenderá más sobre `read-tree` y sus amigos en <>, pero por ahora sepa que este interpreta el árbol raíz de un branch en su area de staging y directorio de trabajo. -Sólo cambiamos de vuelta a su branch `master`, e integramos el branch `rack_branch` al subdirectorio `rack` de nuestro branch `master` de nuestro proyecto principal: +Aprenderá más sobre `read-tree` y sus amigos en <>, pero por ahora sepa que éste interpreta el árbol raíz de una 'branch' en su ''área de staging' y 'directorio de trabajo'. +Sólo cambiamos de vuelta a su 'branch' `master`, e integramos la 'branch' `rack_branch` al subdirectorio `rack` de nuestra 'branch' `master` de nuestro proyecto principal: [source,console] ---- $ git read-tree --prefix=rack/ -u rack_branch ---- -Cuando hacemos commit, parece que tenemos todos los archivos Rack bajo ese subdirectorio - como si los hubiéramos copiado de un tarball. -Lo interesante es que podemos facilmente converger cambios de uno de los branchs al otro. -Entonces, si el proyecto Rack se actualiza, podemos atraer cambios río arriba alternando a esa branch e incorporando: +Cuando hacemos ``commit'', parece que tenemos todos los archivos Rack bajo ese subdirectorio - como si los hubiéramos copiado de un tarball. +Lo interesante es que podemos facilmente converger cambios de una de las 'branchs' a la otra. +Entonces, si el proyecto Rack se actualiza, podemos atraer cambios río arriba alternando a esa 'branch' e incorporando: [source,console] ---- @@ -66,8 +66,8 @@ $ git checkout rack_branch $ git pull ---- -Luego, podemos converger de vuelta esos cambios a nuestro branch `master`. -Para incorporar los cambios y rellenar previamente el mensaje de commit, utilice las opciones `--squash` y `--no-commit`, así como la estrategia de convergencia recursiva de la opción `-Xsubtree`. (La estrategia recursiva está aquí por defecto, pero la incluímos para aclarar.) +Luego, podemos converger de vuelta esos cambios a nuestr 'branch' `master`. +Para incorporar los cambios y rellenar previamente el mensaje de ``commit'', utilice las opciones `--squash` y `--no-commit`, así como la estrategia de convergencia recursiva de la opción `-Xsubtree`. (La estrategia recursiva está aquí por defecto, pero la incluímos para aclarar.) [source,console] ---- @@ -78,19 +78,19 @@ Automatic merge went well; stopped before committing as requested ---- Todos los cambios del proyeto Rack se convergieron y están listos para ser encomendados localmente. -También puede hacer lo opuesto - hacer cambios en el subdirectorio `rack` de su master branch y luego convergerlos a su branch `rack_branch` más adelante para entregarlos a los mantenedores o empujarlos río arriba. +También puede hacer lo opuesto - hacer cambios en el subdirectorio `rack` de su `master branch` y luego convergerlos a su 'branch' `rack_branch` más adelante para entregarlos a los mantenedores o empujarlos río arriba. -Esto nos deja una manera de tener un flujo de trabajo algo similar al flujo de trabajo de submódulo sin utilizar submódulos (de los cuales hablaremos en <>). Podemos mantener branchs con otros proyectos relacionados en nuestro repositorio y convergerlos tipo subárbol a nuestro proyecto ocasionalmente. Esto es bueno por ciertas razones, por ejemplo todo el códido se encomienda a un único lugar. Sin embargo, tiene el defecto de ser un poco más complejo y facilita el cometer errores al reintegrar cambios o empujar accidentalmente un branch a un repositorio con el que no guarda relación. +Esto nos deja una manera de tener un flujo de trabajo algo similar al flujo de trabajo de submódulo sin utilizar submódulos (de los cuales hablamos en <>). Podemos mantener 'branchs' con otros proyectos relacionados en nuestro repositorio y convergerlos tipo subárbol a nuestro proyecto ocasionalmente. Esto es bueno por ciertas razones, por ejemplo, todo el códido se encomienda a un único lugar. Sin embargo, tiene el defecto de ser un poco más complejo y facilita el cometer errores al reintegrar cambios o empujar accidentalmente una 'branch' a un repositorio con el que no guarda relación. -Otra particularidad es que para diferenciar entre lo que tiene en su subdirectorio `rack` y el código en su branch `rack_branch` - para ver si necesita convergerlos - no puede usar el comando `diff` normal. -En lugar de esto, debe ejecutar `git diff-tree` con el branch que desea comparar a: +Otra particularidad es que para diferenciar entre lo que tiene en su subdirectorio `rack` y el código en su 'branch' `rack_branch` - para ver si necesita convergerlos - no puede usar el comando `diff` normal. +En lugar de esto, debe ejecutar `git diff-tree` con la 'branch' que desea comparar: [source,console] ---- $ git diff-tree -p rack_branch ---- -O, para comparar lo que hay en su subdirectorio `rack` con lo que era el branch `master` en el servidor la última vez que usted hizo fetch, ejecute +O, para comparar lo que hay en su subdirectorio `rack` con lo que era la 'branch' `master` en el servidor la última vez que usted hizo fetch, ejecute: [source,console] ----