diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc
index ce154e32..839ea360 100644
--- a/book/07-git-tools/sections/revision-selection.asc
+++ b/book/07-git-tools/sections/revision-selection.asc
@@ -1,19 +1,19 @@
 [[_revision_selection]]
-=== Revision Selection
+=== Revisión por selección 
 
-Git allows you to specify specific commits or a range of commits in several ways.
-They aren’t necessarily obvious but are helpful to know.
+Git te permite especificar ciertos commits o un rango de estos en muchas maneras.
+No son necesariamente obvias, pero es útil conocerlas.
 
-==== Single Revisions
+==== Revisiones individuales 
 
-You can obviously refer to a commit by the SHA-1 hash that it’s given, but there are more human-friendly ways to refer to commits as well.
-This section outlines the various ways you can refer to a single commit.
+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.
 
-==== Short SHA-1
+==== SHA-1 corto
 
-Git is smart enough to figure out what commit you meant to type if you provide the first few characters, as long as your partial SHA-1 is at least four characters long and unambiguous – that is, only one object in the current repository begins with that partial SHA-1.
+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.
 
-For example, to see a specific commit, suppose you run a `git log` command and identify the commit where you added certain functionality:
+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
 ----
 
-In this case, choose `1c002dd....` If you `git show` that commit, the following commands are equivalent (assuming the shorter versions are unambiguous):
+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):
 
 [source,console]
 ----
@@ -47,8 +47,8 @@ $ git show 1c002dd4b536e7479f
 $ git show 1c002d
 ----
 
-Git can figure out a short, unique abbreviation for your SHA-1 values.
-If you pass `--abbrev-commit` to the `git log` command, the output will use shorter values but keep them unique; it defaults to using seven characters but makes them longer if necessary to keep the SHA-1 unambiguous:
+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:
 
 [source,console]
 ----
@@ -58,36 +58,36 @@ ca82a6d changed the version number
 a11bef0 first commit
 ----
 
-Generally, eight to ten characters are more than enough to be unique within a project.
+Generalmente, de ocho a diez caracteres son más que suficientes para ser únicos en un proyecto. 
 
-As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHA-1s overlap more than the first 11 characters.
+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]
-.A SHORT NOTE ABOUT SHA-1
+.UNA BREVE NOTA RESPECTO A SHA-1
 ====
 
-A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value.
-What then?
+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.
+Pero, ¿entonces qué?
 
-If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written.
-If you try to check out that object again at some point, you’ll always get the data of the first object.
+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.
 
-However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80^
-(the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80^
-is 1.2 x 10^24^
-or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
+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^
+(la fórmula para determinar la propabilidad de colisión es `p = (n(n-1)/2) * (1/2^160))`. 2^80^
+es 1.2 x 10^24^
+o 1 millón de millones de millones. Esto es 1,200 veces el ńumero de granos de arena en la Tierra.
 
-Here’s an example to give you an idea of what it would take to get a SHA-1 collision.
-If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (3.6 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision.
-A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
+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. 
 ====
 
 [[_branch_references]]
-==== Branch References
+==== Referencias por rama 
 
-The most straightforward way to specify a commit requires that it has a branch reference pointed at it.
-Then, you can use a branch name in any Git command that expects a commit object or SHA-1 value.
-For instance, if you want to show the last commit object on a branch, the following commands are equivalent, assuming that the `topic1` branch points to `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]
 ----
@@ -95,10 +95,9 @@ $ git show ca82a6dff817ec66f44342007202690a93763949
 $ git show topic1
 ----
 
-If you want to see which specific SHA-1 a branch points to, or if you want to see what any of these examples boils down to in terms of SHA-1s, you can use a Git plumbing tool called `rev-parse`.
-You can see <<_git_internals>> for more information about plumbing tools; basically, `rev-parse` exists for lower-level operations and isn’t designed to be used in day-to-day operations.
-However, it can be helpful sometimes when you need to see what’s really going on.
-Here you can run `rev-parse` on your branch.
+Si se quiere ver a qué SHA-1 apunta un rama en específico, o si se quiere ver lo que cualquiera de estos ejemplos expresa en terminos de SHA-1s, puede utilizar una herramienta de plomería de Git llamada `rev-parse`.
+Se puede ver <<_git_internals>> para más información sobre las herramientas de plomería; básicamente, `rev-parse` existe para operaciones de bajo nivel y no está diseñado para ser utilizado en operaciones diarias.
+Aquí puedes correr `rev-parse` en tu rama.
 
 [source,console]
 ----
@@ -107,11 +106,11 @@ ca82a6dff817ec66f44342007202690a93763949
 ----
 
 [[_git_reflog]]
-==== RefLog Shortnames
+==== Nombres cortos de RefLog 
 
-One of the things Git does in the background while you’re working away is keep a ``reflog'' – a log of where your HEAD and branch references have been for the last few months.
+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.
 
-You can see your reflog by using `git reflog`:
+Se puede ver el reflog utilizando `git reflog`:
 
 [source,console]
 ----
@@ -125,27 +124,27 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 ----
 
-Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history.
-And you can specify older commits with this data, as well.
-If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output:
+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.
+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]
 ----
 $ git show HEAD@{5}
 ----
 
-You can also use this syntax to see where a branch was some specific amount of time ago.
-For instance, to see where your `master` branch was yesterday, you can type
+También se puede utilizar esta sintaxis para ver dónde se encontraba una rama dada una cierta cantidad de tiempo.
+Por ejemplo, para ver dónde se encontraba tu rama `master` ayer, se puede utilizar
 
 [source,console]
 ----
 $ git show master@{yesterday}
 ----
 
-That shows you where the branch tip was yesterday.
-This technique only works for data that’s still in your reflog, so you can’t use it to look for commits older than a few months.
+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.
 
-To see reflog information formatted like the `git log` output, you can run `git log -g`:
+Para ver información sobre reflog en el formato de `git log`, se puede utilizar `git log -g`:
 
 [source,console]
 ----
@@ -167,15 +166,15 @@ Date:   Thu Dec 11 15:08:43 2008 -0800
     Merge commit 'phedders/rdocs'
 ----
 
-It’s important to note that the reflog information is strictly local – it’s a log of what you’ve done in your repository.
-The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository.
-Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago – if you cloned it five minutes ago, you’ll get no results.
+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.
 
-==== Ancestry References
+==== Referencias por ancestros
 
-The other main way to specify a commit is via its ancestry.
-If you place a `^` at the end of a reference, Git resolves it to mean the parent of that commit.
-Suppose you look at the history of your project:
+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]
 ----
@@ -190,7 +189,7 @@ $ git log --pretty=format:'%h %s' --graph
 * 9b29157 add open3_detach to gemspec file list
 ----
 
-Then, you can see the previous commit by specifying `HEAD^`, which means ``the parent of HEAD'':
+Entoces, se puede ver los commits previos especificando `HEAD^`, lo que significa ``el padre de HEAD'':
 
 [source,console]
 ----
@@ -203,9 +202,9 @@ Date:   Thu Dec 11 15:08:43 2008 -0800
     Merge commit 'phedders/rdocs'
 ----
 
-You can also specify a number after the `^` – for example, `d921970^2` means ``the second parent of d921970.''
-This syntax is only useful for merge commits, which have more than one parent.
-The first parent is the branch you were on when you merged, and the second is the commit on the branch that you merged in:
+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ó:
 
 [source,console]
 ----
@@ -224,11 +223,11 @@ Date:   Wed Dec 10 22:22:03 2008 +0000
     Some rdoc changes
 ----
 
-The other main ancestry specification is the `~`.
-This also refers to the first parent, so `HEAD~` and `HEAD^` are equivalent.
-The difference becomes apparent when you specify a number.
-`HEAD~2` means ``the first parent of the first parent,'' or ``the grandparent'' – it traverses the first parents the number of times you specify.
-For example, in the history listed earlier, `HEAD~3` would be
+La otra manera principal de especificar ancestros es el `~`.
+Este también refiere al primer padre, asi que `HEAD~` y `HEAD^` son equivalentes.
+La diferencia se vuelve aparente cuando se especifica un número.
+`HEAD~2` significa ``el primer padre del primer padre,'' o ``el abuelo'' - este recorre el primer padre las veces que se especifiquen.
+Por ejemplo, en el historial listado antes, `HEAD~3` sería
 
 [source,console]
 ----
@@ -240,7 +239,7 @@ Date:   Fri Nov 7 13:47:59 2008 -0500
     ignore *.gem
 ----
 
-This can also be written `HEAD^^^`, which again is the first parent of the first parent of the first parent:
+Esto también puede ser escrito `HEAD^^^`, lo que también es, el primer padre del primer padre del primer padre:
 
 [source,console]
 ----
@@ -252,27 +251,27 @@ Date:   Fri Nov 7 13:47:59 2008 -0500
     ignore *.gem
 ----
 
-You can also combine these syntaxes – you can get the second parent of the previous reference (assuming it was a merge commit) by using `HEAD~3^2`, and so on.
+También se puede combinar estas sintaxis - se puede obtener el segundo padre de la referencia previa ( asumiendo que fue una fusión confirmada) utilizando `HEAD~3^2`, y así sucesivamente.
 
 [[_commit_ranges]]
-==== Commit Ranges
+==== Rangos de Commits
 
-Now that you can specify individual commits, let’s see how to specify ranges of commits.
-This is particularly useful for managing your branches – if you have a lot of branches, you can use range specifications to answer questions such as, ``What work is on this branch that I haven’t yet merged into my main branch?''
+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?''
 
-===== Double Dot
+===== Dos puntos
 
-The most common range specification is the double-dot syntax.
-This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another.
-For example, say you have a commit history that looks like <<double_dot>>.
+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 <<double_dot>>.
 
 [[double_dot]]
 .Example history for range selection.
-image::images/double-dot.png[Example history for range selection.]
+image::images/double-dot.png[Ejemplo historial para un rango de seleción.]
 
-You want to see what is in your experiment branch that hasn’t yet been merged into your master branch.
-You can ask Git to show you a log of just those commits with `master..experiment` – that means ``all commits reachable by experiment that aren’t reachable by master.''
-For the sake of brevity and clarity in these examples, I’ll use the letters of the commit objects from the diagram in place of the actual log output in the order that they would display:
+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:
 
 [source,console]
 ----
@@ -281,8 +280,8 @@ D
 C
 ----
 
-If, on the other hand, you want to see the opposite – all commits in `master` that aren’t in `experiment` – you can reverse the branch names.
-`experiment..master` shows you everything in `master` not reachable from `experiment`:
+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`:
 
 [source,console]
 ----
@@ -291,24 +290,23 @@ F
 E
 ----
 
-This is useful if you want to keep the `experiment` branch up to date and preview what you’re about to merge in.
-Another very frequent use of this syntax is to see what you’re about to push to a remote:
+Esto es útil si se quiere mantener la rama `experiment` actualizada y previsualizar lo que se está a punto de fusionar.
+Otro uso bastante frecuente de esta sintaxis es para ver lo que se está a punto de publicar en remote:
 
 [source,console]
 ----
 $ git log origin/master..HEAD
 ----
 
-This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote.
-If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server.
-You can also leave off one side of the syntax to have Git assume HEAD.
-For example, you can get the same results as in the previous example by typing `git log origin/master..` – Git substitutes HEAD if one side is missing.
+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.
 
-===== Multiple Points
+===== Múltiples puntos
 
-The double-dot syntax is useful as a shorthand; but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren’t in the branch you’re currently on.
-Git allows you to do this by using either the `^` character or `--not` before any reference from which you don’t want to see reachable commits.
-Thus these three commands are equivalent:
+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.
 
 [source,console]
 ----
@@ -317,8 +315,8 @@ $ git log ^refA refB
 $ git log refB --not refA
 ----
 
-This is nice because with this syntax you can specify more than two references in your query, which you cannot do with the double-dot syntax.
-For instance, if you want to see all commits that are reachable from `refA` or `refB` but not from `refC`, you can type one of these:
+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:
 
 [source,console]
 ----
@@ -326,14 +324,14 @@ $ git log refA refB ^refC
 $ git log refA refB --not refC
 ----
 
-This makes for a very powerful revision query system that should help you figure out what is in your branches.
+Esto lo convierte en un sistema de consultas muy poderoso que debería ayudar a descubrir qué hay en sus ramas.
 
 [[_triple_dot]]
-===== Triple Dot
+===== Tres puntos
 
-The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them.
-Look back at the example commit history in <<double_dot>>.
-If you want to see what is in `master` or `experiment` but not any common references, you can run
+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 <<double_dot>>.
+Si se quiere ver lo que está en `master` o `experiment` pero no en ambos, se puede utilizar
 
 [source,console]
 ----
@@ -344,10 +342,10 @@ D
 C
 ----
 
-Again, this gives you normal `log` output but shows you only the commit information for those four commits, appearing in the traditional commit date ordering.
+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.
 
-A common switch to use with the `log` command in this case is `--left-right`, which shows you which side of the range each commit is in.
-This helps make the data more useful:
+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]
 ----
@@ -358,4 +356,4 @@ $ git log --left-right master...experiment
 > C
 ----
 
-With these tools, you can much more easily let Git know what commit or commits you want to inspect.
+Con estas herramientas, se puede hacer saber más facilmente a Git qué commit o commits desea inspecionar.
diff --git a/status.json b/status.json
index be6a7d2f..69572fb4 100644
--- a/status.json
+++ b/status.json
@@ -60,7 +60,7 @@
     },
     "07-git-tools": {
       "1-git-tools.asc": 0,
-      "sections/advanced-merging.asc": 0,
+      "sections/advanced-merging.asc": 100,
       "sections/bundling.asc": 0,
       "sections/credentials.asc": 0,
       "sections/debugging.asc": 0,