Merge pull request #136 from DiegoFRamirez/new_corrections

Review 'book directory' folders 01-02 finished

Author: andres-mancera

book/01-introduction/sections/about-version-control.asc

@@ -8,9 +8,9 @@ Si eres diseñador gráfico o de web y quieres mantener cada versión de una ima
 ==== Sistemas de Control de Versiones Locales
 
 (((version control,local)))
-Un método de control de versiones usado por muchas personas es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son ingeniosos).  Este método es muy común porque es muy sencillo, pero también es tremendamente propenso a errores.  Es fácil olvidar en qué directorio te encuentras, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no querías.
+Un método de control de versiones, usado por muchas personas, es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son ingeniosos).  Este método es muy común porque es muy sencillo, pero también es tremendamente propenso a errores.  Es fácil olvidar en qué directorio te encuentras y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no querías.
 
-Para afrontar este problema los programadores desarrollaron hace tiempo VCS locales que contenían una simple base de datos en la que se llevaba el registro de todos los cambios realizados a los archivos.
+Para afrontar este problema los programadores desarrollaron hace tiempo VCS locales que contenían una simple base de datos, en la que se llevaba el registro de todos los cambios realizados a los archivos.
 
 .control de versiones local.
 image::images/local.png[Local version control diagram]
@@ -20,7 +20,7 @@ Una de las herramientas de control de versiones más popular fue un sistema llam
 ==== Sistemas de Control de Versiones Centralizados
 
 (((version control,centralized)))
-El siguiente gran problema con el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas.  Los sistemas de Control de Versiones Centralizados (CVCS por sus siglas en inglés) fueron desarrollados para solucionar este problema.  Estos sistemas, como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central.  (((CVS)))(((Subversion)))(((Perforce)))
+El siguiente gran problema con el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas.  Los sistemas de Control de Versiones Centralizados (CVCS por sus siglas en inglés) fueron desarrollados para solucionar este problema.  Estos sistemas, como CVS, Subversion y Perforce, tienen un único servidor que contiene todos los archivos versionados y varios clientes que descargan los archivos desde ese lugar central.  (((CVS)))(((Subversion)))(((Perforce)))
 Este ha sido el estándar para el control de versiones por muchos años.
 
 .Control de versiones centralizado.

book/01-introduction/sections/basics.asc

@@ -9,7 +9,7 @@ La principal diferencia entre Git y cualquier otro VCS (incluyendo Subversion y
 .Almacenamiento de datos como cambios en una versión de la base de cada archivo.
 image::images/deltas.png[Storing data as changes to a base version of each file.]
 
-Git no maneja ni almacena sus datos de esta forma.  Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura.  Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente toma una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa copia instantánea.  Para ser eficiente, si los archivos no se han modificado Git no almacena el archivo de nuevo, sino un enlace al archivo anterior idéntico que ya tiene almacenado.  Git maneja sus datos como una secuencia de copias instantáneas.
+Git no maneja ni almacena sus datos de esta forma.  Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura.  Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente toma una foto del aspecto de todos tus archivos en ese momento y guarda una referencia a esa copia instantánea.  Para ser eficiente, si los archivos no se han modificado Git no almacena el archivo de nuevo, sino un enlace al archivo anterior idéntico que ya tiene almacenado.  Git maneja sus datos como una secuencia de copias instantáneas.
 
 .Almacenamiento de datos como instantáneas del proyecto a través del tiempo.
 image::images/snapshots.png[Git stores data as snapshots of the project over time.]
@@ -20,7 +20,7 @@ Esta es una diferencia importante entre Git y prácticamente todos los demás VC
 
 La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para funcionar.  Por lo general no se necesita información de ningún otro computador de tu red.  Si estás acostumbrado a un CVCS donde la mayoría de las operaciones tienen el costo adicional del retardo de la red, este aspecto de Git te va a hacer pensar que los dioses de la velocidad han bendecido Git con poderes sobrenaturales.  Debido a que tienes toda la historia del proyecto ahí mismo, en tu disco local, la mayoría de las operaciones parecen prácticamente inmediatas.
 
-Por ejemplo, para navegar por la historia del proyecto, Git no necesita conectarse al servidor para obtener la historia y mostrártela - simplemente la lee directamente de tu base de datos local.  Esto significa que ves la historia del proyecto casi instantáneamente.  Si quieres ver los cambios introducidos en un archivo entre la versión actual y la de hace un mes, Git puede buscar el archivo hace un mes y hacer un cálculo de diferencias localmente, en lugar de tener que pedirle a un servidor remoto que lo haga u obtener una versión antigua desde la red y hacerlo de manera local.
+Por ejemplo, para navegar por la historia del proyecto, Git no necesita conectarse al servidor para obtener la historia y mostrártela - simplemente la lee directamente de tu base de datos local.  Esto significa que ves la historia del proyecto casi instantáneamente.  Si quieres ver los cambios introducidos en un archivo entre la versión actual y la de hace un mes, Git puede buscar el archivo de hace un mes y hacer un cálculo de diferencias localmente, en lugar de tener que pedirle a un servidor remoto que lo haga, u obtener una versión antigua desde la red y hacerlo de manera local.
 
 Esto también significa que hay muy poco que no puedes hacer si estás desconectado o sin VPN.  Si te subes a un avión o a un tren y quieres trabajar un poco, puedes confirmar tus cambios felizmente hasta que consigas una conexión de red para subirlos.  Si te vas a casa y no consigues que tu cliente VPN funcione correctamente, puedes seguir trabajando.  En muchos otros sistemas, esto es imposible o muy engorroso.  En Perforce, por ejemplo, no puedes hacer mucho cuando no estás conectado al servidor.  En Subversion y CVS, puedes editar archivos, pero no puedes confirmar los cambios a tu base de datos (porque tu base de datos no tiene conexión).  Esto puede no parecer gran cosa, pero te sorprendería la diferencia que puede suponer.
 
@@ -35,21 +35,21 @@ El mecanismo que usa Git para generar esta suma de comprobación se conoce como
 24b9da6552252987aa493b52f8696cd6d3b00373
 ----
 
-Verás estos valores hash por todos lados en Git porque son usados con mucha frecuencia.  De hecho, Git guarda todo no por nombre de archivo, sino por el valor hash de sus contenidos.
+Verás estos valores hash por todos lados en Git, porque son usados con mucha frecuencia.  De hecho, Git guarda todo no por nombre de archivo, sino por el valor hash de sus contenidos.
 
 ==== Git generalmente solo añade información
 
-Cuando realizas acciones en Git, casi todas ellas solo añaden información a la base de datos de Git.  Es muy difícil conseguir que el sistema haga algo que no se pueda enmendar, o que de algún modo borre información.  Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía.  Pero después de confirmar una copia instantánea en Git es muy difícil de perderla, especialmente si envías tu base de datos a otro repositorio con regularidad.
+Cuando realizas acciones en Git, casi todas ellas sólo añaden información a la base de datos de Git.  Es muy difícil conseguir que el sistema haga algo que no se pueda enmendar, o que de algún modo borre información.  Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía.  Pero después de confirmar una copia instantánea en Git es muy difícil perderla, especialmente si envías tu base de datos a otro repositorio con regularidad.
 
 Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de estropear gravemente las cosas.  Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver <<ch02-git-basics#r_undoing>>.
 
 ==== Los Tres Estados
 
-Ahora presta atención.  Esto es lo más importante que debes recordar acerca de Git si quieres que el resto de tu proceso de aprendizaje prosiga sin problemas.  Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged).  Confirmado significa que los datos están almacenados de manera segura en tu base de datos local.  Modificado significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.  Preparado significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.
+Ahora presta atención.  Esto es lo más importante que debes recordar acerca de Git si quieres que el resto de tu proceso de aprendizaje prosiga sin problemas.  Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged).  Confirmado: significa que los datos están almacenados de manera segura en tu base de datos local.  Modificado: significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.  Preparado: significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.
 
 Esto nos lleva a las tres secciones principales de un proyecto de Git:  El directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).
 
-.Directorio de trabajo, área de almacenamiento, y el directorio Git.
+.Directorio de trabajo, área de almacenamiento y el directorio Git.
 image::images/areas.png["Working directory, staging area, and Git directory."]
 
 El directorio de Git es donde se almacenan los metadatos y la base de datos de objetos para tu proyecto.  Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otra computadora.

book/01-introduction/sections/command-line.asc

@@ -1,7 +1,7 @@
 === La Línea de Comandos
 
-Existen muchas formas de usar Git.  Por un lado tenemos las herramientas originales de línea de comandos, y por otro lado tenemos una gran variedad de interfaces de usuario con distintas capacidades.  En ese libro vamos a utilizar Git desde la línea de comandos.  La línea de comandos es el único lugar en donde puedes ejecutar *todos* los comandos de Git - la mayoría de interfaces gráficas de usuario solo implementan una parte de las características de Git por motivos de simplicidad.
+Existen muchas formas de usar Git.  Por un lado tenemos las herramientas originales de línea de comandos, y por otro lado tenemos una gran variedad de interfaces de usuario con distintas capacidades.  En este libro vamos a utilizar Git desde la línea de comandos.  La línea de comandos es el único lugar en donde puedes ejecutar *todos* los comandos de Git - la mayoría de interfaces gráficas de usuario solo implementan una parte de las características de Git por motivos de simplicidad.
 Si tú sabes cómo realizar algo desde la línea de comandos, seguramente serás capaz de averiguar cómo hacer lo mismo desde una interfaz gráfica.  Sin embargo, la relación opuesta no es necesariamente cierta.
 Así mismo, la decisión de qué cliente gráfico utilizar depende totalmente de tu gusto, pero _todos_ los usuarios tendrán las herramientas de línea de comandos instaladas y disponibles.
 
-Nosotros esperamos que sepas cómo abrir el Terminal en Mac, o el "Command Prompt" o "Powershell" en Windows.  Si no entiendes de lo que estamos hablando aquí, te recomendamos que hagas una pausa para investigar acerca de esto de tal forma que puedas entender el resto de las explicaciones y descripciones que siguen en este libro.
+Nosotros esperamos que sepas cómo abrir el Terminal en Mac, o el "Command Prompt" o "Powershell" en Windows.  Si no entiendes de lo que estamos hablando aquí, te recomendamos que hagas una pausa para investigar acerca de esto, de tal forma que puedas entender el resto de las explicaciones y descripciones que siguen en este libro.

book/01-introduction/sections/first-time-setup.asc

@@ -1,16 +1,16 @@
 [[r_first_time]]
 === Configurando Git por primera vez
 
-Ahora que tienes Git en tu sistema, vas a querer hacer algunas cosas para personalizar tu entorno de Git.  
+Ahora que tienes Git en tu sistema, vas a querer hacer algunas cosas para personalizar tu entorno de Git.
 Es necesario hacer estas cosas solamente una vez en tu computadora, y se mantendrán entre actualizaciones.
 También puedes cambiarlas en cualquier momento volviendo a ejecutar los comandos correspondientes.
 
-Git trae una herramienta llamada `git config` que te permite obtener y establecer variables de configuración que controlan el aspecto y funcionamiento de Git.(((git commands, config)))
+Git trae una herramienta llamada `git config`, que te permite obtener y establecer variables de configuración que controlan el aspecto y funcionamiento de Git.(((git commands, config)))
 Estas variables pueden almacenarse en tres sitios distintos:
 
 1. Archivo `/etc/gitconfig`:  Contiene valores para todos los usuarios del sistema y todos sus repositorios.  Si pasas la opción `--system` a `git config`, lee y escribe específicamente en este archivo.
-2. Archivo `~/.gitconfig` o `~/.config/git/config`:  Este archivo es específico a tu usuario.  Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`.
-3. Archivo `config` en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente:  Este archivo es específico al repositorio actual.
+2. Archivo `~/.gitconfig` o `~/.config/git/config`:  Este archivo es específico de tu usuario.  Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`.
+3. Archivo `config` en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente:  Este archivo es específico del repositorio actual.
 
 Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`.
 
@@ -19,7 +19,7 @@ También busca el archivo `/etc/gitconfig`, aunque esta ruta es relativa a la ra
 
 ==== Tu Identidad
 
-Lo primero que deberás hacer cuando instales Git es establecer tu nombre de usuario y dirección de correo electrónico.  
+Lo primero que deberás hacer cuando instales Git es establecer tu nombre de usuario y dirección de correo electrónico.
 Esto es importante porque los "commits" de Git usan esta información, y es introducida de manera inmutable en los commits que envías:
 
 [source,console]
@@ -28,15 +28,15 @@ $ git config --global user.name "John Doe"
 $ git config --global user.email [email protected]
 ----
 
-De nuevo, solo necesitas hacer esto una vez si especificas la opción `--global`, ya que Git siempre usará esta información para todo lo que hagas en ese sistema.  
+De nuevo, sólo necesitas hacer esto una vez si especificas la opción `--global`, ya que Git siempre usará esta información para todo lo que hagas en ese sistema.
 Si quieres sobrescribir esta información con otro nombre o dirección de correo para proyectos específicos, puedes ejecutar el comando sin la opción `--global` cuando estés en ese proyecto.
 
 Muchas de las herramientas de interfaz gráfica te ayudarán a hacer esto la primera vez que las uses.
 
 ==== Tu Editor
 
 Ahora que tu identidad está configurada, puedes elegir el editor de texto por defecto que se utilizará cuando Git necesite que introduzcas un mensaje.
-Si no indicas nada, Git usa el editor por defecto de tu sistema, que generalmente es Vim.  
+Si no indicas nada, Git usará el editor por defecto de tu sistema, que generalmente es Vim.
 Si quieres usar otro editor de texto como Emacs, puedes hacer lo siguiente:
 
 [source,console]
@@ -66,10 +66,10 @@ color.diff=auto
 ...
 ----
 
-Puede que veas claves repetidas, porque Git lee la misma clave de distintos archivos (`/etc/gitconfig` y `~/.gitconfig`, por ejemplo). 
-En ese caso, Git usa el último valor para cada clave única que ve.
+Puede que veas claves repetidas, porque Git lee la misma clave de distintos archivos (`/etc/gitconfig` y `~/.gitconfig`, por ejemplo).
+En estos casos, Git usa el último valor para cada clave única que ve.
 
-También puedes comprobar qué valor que Git utilizará para una clave específica ejecutando `git config <key>`:(((git commands, config)))
+También puedes comprobar el valor que Git utilizará para una clave específica ejecutando `git config <key>`:(((git commands, config)))
 
 [source,console]
 ----

book/01-introduction/sections/history.asc

@@ -4,12 +4,12 @@ Como muchas de las grandes cosas en esta vida, Git comenzó con un poco de destr
 
 El kernel de Linux es un proyecto de software de código abierto con un alcance bastante amplio.(((Linux)))  Durante la mayor parte del mantenimiento del kernel de Linux (1991-2002), los cambios en el software se realizaban a través de parches y archivos.  En el 2002, el proyecto del kernel de Linux empezó a usar un DVCS propietario llamado BitKeeper.(((BitKeeper)))
 
-En el 2005, la relación entre la comunidad que desarrollaba el kernel de Linux y la compañía que desarrollaba BitKeeper se vino abajo, y la herramienta dejó de ser ofrecida de manera gratuita.  Esto impulsó a la comunidad de desarrollo de Linux (y en particular a Linus Torvalds, el creador de Linux) a desarrollar su propia herramienta basada en algunas de las lecciones que aprendieron mientras usaban BitKeeper.  Algunos de los objetivos del nuevo sistema fueron los siguientes:
+En el 2005, la relación entre la comunidad que desarrollaba el kernel de Linux y la compañía que desarrollaba BitKeeper se vino abajo y la herramienta dejó de ser ofrecida de manera gratuita.  Esto impulsó a la comunidad de desarrollo de Linux (y en particular a Linus Torvalds, el creador de Linux) a desarrollar su propia herramienta basada en algunas de las lecciones que aprendieron mientras usaban BitKeeper.  Algunos de los objetivos del nuevo sistema fueron los siguientes:
 
 *  Velocidad
 *  Diseño sencillo
 *  Gran soporte para desarrollo no lineal (miles de ramas paralelas)
 *  Completamente distribuido
 *  Capaz de manejar grandes proyectos (como el kernel de Linux) eficientemente (velocidad y tamaño de los datos)
 
-Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales.  Es tremendamente rápido, muy eficiente con grandes proyectos, y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <<ch03-git-branching#ch03-git-branching>>)
+Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales.  Es tremendamente rápido, muy eficiente con grandes proyectos y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <<ch03-git-branching#ch03-git-branching>>)