Merge pull request #137 from DiegoFRamirez/new_corrections

Review about 0-3-git-branching finished

Author: andres-mancera

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -12,7 +12,7 @@ En este momento, recibes una llamada avisándote de un problema crítico que has
 . Vuelves a la rama de producción original.
 . Creas una nueva rama para el problema crítico y lo resuelves trabajando en ella.
 . Tras las pertinentes pruebas, fusionas (merge) esa rama y la envías (push) a la rama de producción.
-. Vuelves a la rama del tema en que andabas antes de la llamada y continuas tu trabajo.
+. Vuelves a la rama del tema en que andabas antes de la llamada y continúas tu trabajo.
 
 [[r_basic_branching]]
 ==== Procedimientos Básicos de Ramificación
@@ -23,7 +23,7 @@ Imagina que estas trabajando en un proyecto y tienes un par de confirmaciones (c
 .Un registro de confirmaciones corto y sencillo
 image::images/basic-branching-1.png[Un registro de confirmaciones corto y sencillo.]
 
-Decides trabajar en el problema #53, según el sistema que tu compañía utiliza para llevar seguimiento de los problemas.
+Decides trabajar en el problema #53, según el sistema que tu compañía utiliza para llevar el  seguimiento de los problemas.
 Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`:
 
 [source,console]
@@ -32,7 +32,7 @@ $ git checkout -b iss53
 Switched to a new branch "iss53"
 ----
 
-Esto es un atajo a:
+Esto es un atajo para:
 
 [source,console]
 ----
@@ -59,7 +59,7 @@ Entonces, recibes una llamada avisándote de otro problema urgente en el sitio w
 Al usar Git, no necesitas mezclar el nuevo problema con los cambios que ya habías realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción.
 Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de allí.
 
-Pero, antes de poder hacer eso, hemos de tener en cuenta que si tenemos cambios aún no confirmados en el directorio de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.
+Pero, antes de poder hacer eso, hemos de tomar en cuenta que si tenemos cambios aún no confirmados en el directorio de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.
 Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas.
 Y, para ello, tenemos algunos procedimientos (stash y corregir confirmaciones), que vamos a ver más adelante en <<ch07-git-tools#r_git_stashing>>.
 Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama `master` sin problemas:
@@ -90,7 +90,7 @@ $ git commit -a -m 'fixed the broken email address'
 .Rama `hotfix` basada en la rama `master` original
 image::images/basic-branching-4.png[Rama `hotfix` basada en la rama `master` original.]
 
-Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, e incorporar los cambios a la rama `master` para ponerlos en producción.
+Puedes realizar las pruebas oportunas, asegurarte de que la solución es correcta, e incorporar los cambios a la rama `master` para ponerlos en producción.
 Esto se hace con el comando `git merge`:(((git commands, merge)))
 
 [source,console]

book/03-git-branching/sections/branch-management.asc

@@ -29,7 +29,7 @@ $ git branch -v
 
 Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas que han sido fusionadas (o que no lo han sido) con la rama actualmente activa.
 Para ello, Git dispone de las opciones `--merged` y `--no-merged`.
-Si deseas ver las ramas que han sido fusionadas en la rama activa, puedes lanzar el comando `git branch --merged`:
+Si deseas ver las ramas que han sido fusionadas con la rama activa, puedes lanzar el comando `git branch --merged`:
 
 [source,console]
 ----
@@ -50,7 +50,7 @@ $ git branch --no-merged
 ----
 
 Esto nos muestra la otra rama del proyecto.
-Debido a que contiene trabajos sin fusionar, al intentarla borrarla con `git branch -d`, el comando nos dará un error:
+Debido a que contiene trabajos sin fusionar, al intentar borrarla con `git branch -d`, el comando nos dará un error:
 
 [source,console]
 ----
@@ -59,4 +59,4 @@ error: The branch 'testing' is not fully merged.
 If you are sure you want to delete it, run 'git branch -D testing'.
 ----
 
-Si realmente deseas borrar la rama, y perder el trabajo contenido en ella, puedes forzar el borrado con la opción `-D`; tal y como indica el mensaje de ayuda.
+Si realmente deseas borrar la rama y perder el trabajo contenido en ella, puedes forzar el borrado con la opción `-D`; tal y como indica el mensaje de ayuda.

book/03-git-branching/sections/nutshell.asc

@@ -25,7 +25,7 @@ En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para
 .Una confirmación y sus árboles
 image::images/commit-and-tree.png[Una confirmación y sus árboles.]
 
-Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardará un apuntador su confirmación precedente.
+Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardará un apuntador a su confirmación precedente.
 
 .Confirmaciones y sus predecesoras
 image::images/commits-and-parents.png[Confirmaciones y sus predecesoras.]
@@ -37,7 +37,7 @@ En cada confirmación de cambios que realicemos, la rama irá avanzando automát
 
 [NOTE]
 ====
-La rama ``master'' en Git no es una rama especial.(((master)))
+La rama ``master'' en Git, no es una rama especial.(((master)))
 Es como cualquier otra rama.
 La única razón por la cual aparece en casi todos los repositorios es porque es la que crea por defecto el comando `git init` y la gente no se molesta en cambiarle el nombre.
 ====
@@ -67,7 +67,7 @@ image::images/two-branches.png[Dos ramas apuntando al mismo grupo de confirmacio
 Y, ¿cómo sabe Git en qué rama estás en este momento?
 Pues..., mediante un apuntador especial denominado HEAD.
 Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS.
-En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento, en este caso la rama `master`; pues el comando `git branch` solamente crea una nueva rama, y no salta a dicha rama.
+En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento, en este caso la rama `master`; pues el comando `git branch` solamente crea una nueva rama, pero no salta a dicha rama.
 
 .Apuntador HEAD a la rama donde estás actualmente
 image::images/head-to-master.png[Apuntador HEAD a la rama donde estás actualmente.]
@@ -102,7 +102,7 @@ Esto mueve el apuntador HEAD a la rama `testing`.
 image::images/head-to-testing.png[El apuntador HEAD apunta a la rama actual.]
 
 ¿Cuál es el significado de todo esto?
-Bueno... lo veremos tras realizar otra confirmación de cambios:
+Bueno..., lo veremos tras realizar otra confirmación de cambios:
 
 [source,console]
 ----
@@ -126,7 +126,7 @@ image::images/checkout-master.png[HEAD apunta a otra rama cuando hacemos un salt
 
 Este comando realiza dos acciones:
 Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejándolos tal y como estaban en la última instantánea confirmada en dicha rama `master`.
-Esto supone que los cambios que hagas desde este momento en adelante divergirán de la antigua versión del proyecto.
+Esto supone que los cambios que hagas desde este momento en adelante, divergirán de la antigua versión del proyecto.
 Básicamente, lo que se está haciendo es rebobinar el trabajo que habías hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente.
 
 [NOTE]
@@ -173,7 +173,7 @@ Crear una nueva rama es tan rápido y simple como escribir 41 bytes en un archiv
 
 Esto contrasta fuertemente con los métodos de ramificación usados por otros sistemas de control de versiones, en los que crear una rama nueva supone el copiar todos los archivos del proyecto a un directorio adicional nuevo.
 Esto puede llevar segundos o incluso minutos, dependiendo del tamaño del proyecto; mientras que en Git el proceso es siempre instantáneo.
-Y, además, debido a que se almacenan también los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar.
+Y además, debido a que se almacenan también los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar.
 Animando así a los desarrolladores a utilizar ramificaciones frecuentemente.
 
 Vamos a ver el por qué merece la pena hacerlo así.

book/03-git-branching/sections/rebasing.asc

@@ -18,9 +18,9 @@ Realiza una fusión a tres bandas entre las dos últimas instantáneas de cada r
 .Fusionar una rama para integrar el registro de trabajos divergentes
 image::images/basic-rebase-2.png[Fusionar una rama para integrar el registro de trabajos divergentes.]
 
-Sin embargo, también hay otra forma de hacerlo: puedes coger los cambios introducidos en C3 y reaplicarlos encima de C4.
+Sin embargo, también hay otra forma de hacerlo: puedes capturar los cambios introducidos en C3 y reaplicarlos encima de C4.
 Esto es lo que en Git llamamos _reorganizar_ (_rebasing_, en inglés).
-Con el comando `git rebase`, puedes coger todos los cambios confirmados en una rama, y reaplicarlos sobre otra.(((git commands, rebase)))
+Con el comando `git rebase`, puedes capturar todos los cambios confirmados en una rama y reaplicarlos sobre otra.(((git commands, rebase)))
 
 Por ejemplo, puedes lanzar los comandos:
 
@@ -32,7 +32,7 @@ First, rewinding head to replay your work on top of it...
 Applying: added staged command
 ----
 
-Haciendo que Git vaya al ancestro común de ambas ramas (donde estás actualmente y de donde quieres reorganizar), saque las diferencias introducidas por cada confirmación en la rama donde estás, guarde esas diferencias en archivos temporales, reinicie (reset) la rama actual hasta llevarla a la misma confirmación en la rama de donde quieres reorganizar, y, finalmente, vuelva a aplicar ordenadamente los cambios.
+Haciendo que Git vaya al ancestro común de ambas ramas (donde estás actualmente y de donde quieres reorganizar), saque las diferencias introducidas por cada confirmación en la rama donde estás, guarde esas diferencias en archivos temporales, reinicie (reset) la rama actual hasta llevarla a la misma confirmación que la rama de donde quieres reorganizar, y finalmente, vuelva a aplicar ordenadamente los cambios.
 
 .Reorganizando sobre C3 los cambios introducidos en C4
 image::images/basic-rebase-3.png[Reorganizando sobre C3 los cambios introducidos en C4.]
@@ -56,7 +56,7 @@ Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus con
 En casos como esos, puedes trabajar sobre una rama y luego reorganizar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal.
 De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
 
-Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una reorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea; lo único diferente es el historial.
+Cabe destacar que, la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una reorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea; lo único diferente es el historial.
 La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera, mientras que la fusión combina entre sí los dos puntos finales de ambas ramas.
 
 ==== Algunas Reorganizaciones Interesantes
@@ -143,7 +143,7 @@ Si sigues esta recomendación, no tendrás problemas.
 Pero si no lo haces, la gente te odiará y serás despreciado por tus familiares y amigos.
 
 Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes.
-Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí; y después vas tú y las reescribes con `git rebase` y las vuelves a enviar (push); tus colaboradores tendrán que refusionar (re-merge) su trabajo  y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo.
+Si envías (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí; y después vas tú y las reescribes con `git rebase` y las vuelves a enviar (push); tus colaboradores tendrán que refusionar (re-merge) su trabajo  y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo.
 
 Veamos con un ejemplo como reorganizar trabajo que has hecho público puede causar problemas.
 Imagínate que haces un clon desde un servidor central, y luego trabajas sobre él.
@@ -162,7 +162,7 @@ A continuación, la persona que había llevado cambios al servidor central decid
 Tu te traes (fetch) esos nuevos cambios desde el servidor.
 
 [[r_pre_merge_rebase_work]]
-.Alguien envio (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habías basado tu trabajo
+.Alguien envió (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habías basado tu trabajo
 image::images/perils-of-rebasing-3.png[Alguien envií (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habías basado tu trabajo.]
 
 Ahora los dos están en un aprieto.
@@ -206,7 +206,7 @@ También puedes simplificar el proceso si ejecutas `git pull --rebase` en vez de
 
 Si sueles utilizar `git pull` y quieres que la opción `--rebase` esté activada por defecto, puedes asignar el valor de configuración `pull.rebase` haciendo algo como esto `git config --global pull.rebase true`.
 
-Si consideras la reorganización como una manera de limpiar tu trabajo y tus confirmaciones antes de enviarlas (push), y si solo reorganizas confirmaciones (commits) que nunca han estado disponibles públicamente, no tendrás problemas.
+Si consideras la reorganización como una manera de limpiar tu trabajo y tus confirmaciones antes de enviarlas (push), y si sólo reorganizas confirmaciones (commits) que nunca han estado disponibles públicamente, no tendrás problemas.
 Si reorganizas (rebase) confirmaciones (commits) que ya estaban disponibles públicamente y la gente había basado su trabajo en ellas, entonces prepárate para tener problemas, frustrar a tu equipo y ser despreciado por tus compañeros.
 
 Si tu compañero o tú ven que aun así es necesario hacerlo en algún momento, asegúrense que todos sepan que deben ejecutar `git pull --rebase` para intentar aliviar en lo posible la frustración.
@@ -221,14 +221,14 @@ Para algunos, el historial de confirmaciones de tu repositorio es *un registro d
 Un documento histórico, valioso por sí mismo y que no debería ser alterado.
 Desde este punto de vista, cambiar el historial de confirmaciones es casi como blasfemar; estarías _mintiendo_ sobre lo que en verdad ocurrió.
 ¿Y qué pasa si hay una serie desastrosa de fusiones confirmadas?
-Nada. Así fue como ocurrió y el repositorio debería tener un registro de esto para la posteridad.
+Nada. Así fué como ocurrió y el repositorio debería tener un registro de esto para la posteridad.
 
-La otra forma de verlo es que el historial de confirmaciones es *la historia de cómo se hizo tu proyecto.*
+La otra forma de verlo puede ser que, el historial de confirmaciones es *la historia de cómo se hizo tu proyecto.*
 Tú no publicarías el primer borrador de tu novela, y el manual de cómo mantener tus programas también debe estar editado con mucho cuidado.
 Esta es el área que utiliza herramientas como `rebase` y `filter-branch` para contar la historia de la mejor manera para los futuros lectores.
 
-Ahora, sobre qué es mejor si fusionar o reorganizar: verás que la respuesta no es tan sencilla.
+Ahora, sobre si es mejor  fusionar o reorganizar: verás que la respuesta no es tan sencilla.
 Git es una herramienta poderosa que te permite hacer muchas cosas con tu historial, y cada equipo y cada proyecto es diferente.
 Ahora que conoces cómo trabajan ambas herramientas, será cosa tuya decidir cuál de las dos es mejor para tu situación en particular.
 
-Normalmente, la manera de sacar lo mejor de ambas es reorganizar tu trabajo local, que aun no has compartido, antes de enviarlo a algún lugar; pero nunca reorganizar nada que ya haya sido compartido.
+Normalmente, la manera de sacar lo mejor de ambas es reorganizar tu trabajo local, que aún no has compartido, antes de enviarlo a algún lugar; pero nunca reorganizar nada que ya haya sido compartido.

book/03-git-branching/sections/remote-branches.asc

@@ -44,7 +44,7 @@ Puedes denominar `teamone` a este remoto al asignarle este nombre a la URL.
 .Añadiendo otro servidor como remoto
 image::images/remote-branches-4.png[Añadiendo otro servidor como remoto.]
 
-Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenias.
+Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenías.
 Debido a que dicho servidor es un subconjunto de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`.
 
 .Seguimiento de la rama remota a través de `teamone/master`
@@ -163,7 +163,7 @@ Branch serverfix set up to track remote branch serverfix from origin.
 Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante `@{upstream}` o mediante el atajo `@{u}`. De esta manera, si estás en la rama `master` y esta sigue a la rama `origin/master`, puedes hacer algo como `git merge @{u}` en vez de `git merge origin/master`.(((+++@{u}+++)))(((+++@{upstream}+++)))
 ====
 
-Si quieres ver las ramas de seguimiento que tienes asignado, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas.
+Si quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas.
 
 [source,console]
 ----
@@ -183,7 +183,7 @@ Es importante destacar que estos números se refieren a la última vez que traji
 ==== Traer y Fusionar
 
 (((pulling)))
-A pesar de que el comando `git fetch` trae todos los cambios del servidor que no tienes, este no modifica tu directorio de trabajo.
+A pesar de que el comando `git fetch` trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo.
 Simplemente obtendrá los datos y dejará que tú mismo los fusiones.
 Sin embargo, existe un comando llamado `git pull`, el cuál básicamente hace `git fetch` seguido por `git merge` en la mayoría de los casos.
 Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos `clone` o `checkout`, `git pull` identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota.
@@ -204,4 +204,4 @@ To https://github.com/schacon/simplegit
  - [deleted]         serverfix
 ----
 
-Básicamente lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.
+Básicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.