From 63bb079fbd31bbc99d0f0ad7ff16d935ba4f1a8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 12:23:39 +0100 Subject: [PATCH 01/10] corregido errores de tipeo y orden --- book/02-git-basics/sections/getting-a-repository.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 3df0c5e9..487949c0 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -2,7 +2,7 @@ === Obteniendo un repositorio Git Puedes obtener un proyecto Git de dos maneras. -La primera es toma un proyecto o directorio existente e importarlo en Git. +La primera es tomar un proyecto o directorio existente e importarlo en Git. La segunda es clonar un repositorio existente en Git desde otro servidor. ==== Inicializando un repositorio en un directorio existente @@ -14,7 +14,7 @@ Si estás empezando a seguir un proyecto existente en Git, debes ir al directori $ git init ---- -Esto crea un subdirectorio nuevo llamado `.git`, el cual contiene todos los archivos del repositorio necesarios – un esqueleto de un repositorio de Git. +Esto crea un subdirectorio nuevo llamado `.git`, el cual contiene todos los archivos necesarios del repositorio – un esqueleto de un repositorio de Git. Todavía no hay nada en tu proyecto que esté bajo seguimiento. Puedes revisar <<_git_internals>> para obtener más información acerca de los archivos presentes en el directorio `.git` que acaba de ser creado.(((git commands, init))) Si deseas empezar a controlar versiones de archivos existentes (a diferencia de un directorio vacío), probablemente deberías comenzar el seguimiento de esos archivos y hacer una confirmación inicial. @@ -35,8 +35,8 @@ En este momento, tienes un repositorio de Git con archivos bajo seguimiento, y u Si deseas obtener una copia de un repositorio Git existente — por ejemplo, un proyecto en el que te gustaría contribuir — el comando que necesitas es `git clone`. Si estás familizarizado con otros sistemas de control de versiones como Subversion, verás que el comando es "clone" en vez de "checkout". Es una distinción importante, ya que Git recibe una copia de casi todos los datos que tiene el servidor. -Cada versión de cada archivo de la historia del proyecto es descargado por defecto cuando ejecutas `git clone`. -De hecho, si el disco de tu servidor se corrompe, puedes usar cualquiera de los clones en cualquiera de los clientes para devolver al servidor al estado en el que estaba cuando fue clonado (puede que pierdas algunos hooks del lado del servidor y demás, pero toda la información acerca de las versiones estará ahí — véase <<_git_on_the_server>> para más detalles. +Cada versión de cada archivo de la historia del proyecto es descargada por defecto cuando ejecutas `git clone`. +De hecho, si el disco de tu servidor se corrompe, puedes usar cualquiera de los clones en cualquiera de los clientes para devolver al servidor al estado en el que estaba cuando fue clonado (puede que pierdas algunos hooks del lado del servidor y demás, pero toda la información acerca de las versiones estará ahí) — véase <<_git_on_the_server>> para más detalles. Puedes clonar un repositorio con `git clone [url]`.(((git commands, clone))) Por ejemplo, si quieres clonar la librería de Git llamada libgit2 puedes hacer algo así: @@ -58,5 +58,5 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit Ese comando hace lo mismo que el anterior, pero el directorio de destino se llamará `mylibgit`. Git te permite usar distintos protocolos de transferencia. -El ejemplo anterior usa el protocolo `https://`, pero también te puede ver `git://` o `usuario@servidor:ruta/del/repositorio.git`que utiliza el protocolo de transferencia SSH. +El ejemplo anterior usa el protocolo `https://`, pero también puedes utilizar `git://` o `usuario@servidor:ruta/del/repositorio.git` que utiliza el protocolo de transferencia SSH. En <<_git_on_the_server>> se explicarán todas las opciones disponibles a la hora de configurar el acceso a tu repositorio de Git, y las ventajas e inconvenientes de cada una. From 65813a46e3df22a47d68c0ce1ccbadcc90d05739 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 12:24:13 +0100 Subject: [PATCH 02/10] =?UTF-8?q?elimino=20la=20coma=20al=20final=20de=20u?= =?UTF-8?q?na=20enumeraci=C3=B3n=20http://www.fundeu.es/consulta/coma-ante?= =?UTF-8?q?s-de-y-900/?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/getting-a-repository.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 487949c0..d68cedb4 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,7 +1,7 @@ [[_getting_a_repo]] === Obteniendo un repositorio Git -Puedes obtener un proyecto Git de dos maneras. +Puedes obtener un proyecto Git de dos maneras. La primera es tomar un proyecto o directorio existente e importarlo en Git. La segunda es clonar un repositorio existente en Git desde otro servidor. @@ -17,7 +17,7 @@ $ git init Esto crea un subdirectorio nuevo llamado `.git`, el cual contiene todos los archivos necesarios del repositorio – un esqueleto de un repositorio de Git. Todavía no hay nada en tu proyecto que esté bajo seguimiento. Puedes revisar <<_git_internals>> para obtener más información acerca de los archivos presentes en el directorio `.git` que acaba de ser creado.(((git commands, init))) -Si deseas empezar a controlar versiones de archivos existentes (a diferencia de un directorio vacío), probablemente deberías comenzar el seguimiento de esos archivos y hacer una confirmación inicial. +Si deseas empezar a controlar versiones de archivos existentes (a diferencia de un directorio vacío), probablemente deberías comenzar el seguimiento de esos archivos y hacer una confirmación inicial. Puedes conseguirlo con unos pocos comandos `git add` para especificar qué archivos quieres controlar, seguidos de un `git commit` para confirmar los cambios: [source,console] @@ -28,13 +28,13 @@ $ git commit -m 'initial project version' ---- Veremos lo que hacen estos comandos más adelante. -En este momento, tienes un repositorio de Git con archivos bajo seguimiento, y una confirmación inicial. +En este momento, tienes un repositorio de Git con archivos bajo seguimiento y una confirmación inicial. [[_git_cloning]] ==== Clonando un repositorio existente -Si deseas obtener una copia de un repositorio Git existente — por ejemplo, un proyecto en el que te gustaría contribuir — el comando que necesitas es `git clone`. -Si estás familizarizado con otros sistemas de control de versiones como Subversion, verás que el comando es "clone" en vez de "checkout". Es una distinción importante, ya que Git recibe una copia de casi todos los datos que tiene el servidor. +Si deseas obtener una copia de un repositorio Git existente — por ejemplo, un proyecto en el que te gustaría contribuir — el comando que necesitas es `git clone`. +Si estás familizarizado con otros sistemas de control de versiones como Subversion, verás que el comando es "clone" en vez de "checkout". Es una distinción importante, ya que Git recibe una copia de casi todos los datos que tiene el servidor. Cada versión de cada archivo de la historia del proyecto es descargada por defecto cuando ejecutas `git clone`. De hecho, si el disco de tu servidor se corrompe, puedes usar cualquiera de los clones en cualquiera de los clientes para devolver al servidor al estado en el que estaba cuando fue clonado (puede que pierdas algunos hooks del lado del servidor y demás, pero toda la información acerca de las versiones estará ahí) — véase <<_git_on_the_server>> para más detalles. @@ -46,8 +46,8 @@ Por ejemplo, si quieres clonar la librería de Git llamada libgit2 puedes hacer $ git clone https://github.com/libgit2/libgit2 ---- -Esto crea un directorio llamado `libgit`, inicializa un directorio `.git` en su interior, descarga toda la información de ese repositorio, y saca una copia de trabajo de la última versión. -Si te metes en el directorio `libgit2`, verás que están los archivos del proyecto, listos para ser utilizados. +Esto crea un directorio llamado `libgit2`, inicializa un directorio `.git` en su interior, descarga toda la información de ese repositorio y saca una copia de trabajo de la última versión. +Si te metes en el directorio `libgit2`, verás que están los archivos del proyecto, listos para ser utilizados. Si quieres clonar el repositorio a un directorio con otro nombre que no sea `libgit2`, puedes especificarlo con la siguiente opción de línea de comandos: [source,console] @@ -57,6 +57,6 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit Ese comando hace lo mismo que el anterior, pero el directorio de destino se llamará `mylibgit`. -Git te permite usar distintos protocolos de transferencia. +Git te permite usar distintos protocolos de transferencia. El ejemplo anterior usa el protocolo `https://`, pero también puedes utilizar `git://` o `usuario@servidor:ruta/del/repositorio.git` que utiliza el protocolo de transferencia SSH. En <<_git_on_the_server>> se explicarán todas las opciones disponibles a la hora de configurar el acceso a tu repositorio de Git, y las ventajas e inconvenientes de cada una. From 5c45129c3f6bc7e3657dd06c7f6894e9d7f70443 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 12:25:09 +0100 Subject: [PATCH 03/10] =?UTF-8?q?creo=20que=20la=20coma=20cortaba=20innece?= =?UTF-8?q?sariamente=20el=20sentido=20de=20la=20oraci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/02-git-basics/sections/getting-a-repository.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index d68cedb4..ed346158 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -47,7 +47,7 @@ $ git clone https://github.com/libgit2/libgit2 ---- Esto crea un directorio llamado `libgit2`, inicializa un directorio `.git` en su interior, descarga toda la información de ese repositorio y saca una copia de trabajo de la última versión. -Si te metes en el directorio `libgit2`, verás que están los archivos del proyecto, listos para ser utilizados. +Si te metes en el directorio `libgit2`, verás que están los archivos del proyecto listos para ser utilizados. Si quieres clonar el repositorio a un directorio con otro nombre que no sea `libgit2`, puedes especificarlo con la siguiente opción de línea de comandos: [source,console] From f4cfc626559fa92e3956b77e57a206d461d99756 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 15:22:20 +0100 Subject: [PATCH 04/10] =?UTF-8?q?primera=20traducci=C3=B3n=20completa=20de?= =?UTF-8?q?=20recording-changes.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/recording-changes.asc | 291 +++++++++--------- 1 file changed, 145 insertions(+), 146 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index ec00e12f..cf85e39e 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,24 +1,24 @@ -=== Recording Changes to the Repository +=== Guardando cambios en el Repositorio -You have a bona fide Git repository and a checkout or working copy of the files for that project. -You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +Ya tienes un repositorio Git y un _checkout_ o copia de trabajo de los archivos de dicho proyecto. +El siguiente paso es realizar algunos cambios y confirmar instantáneas de esos cambios en el repositorio cada vez que el proyecto alcance un estado que quieras conservar. -Remember that each file in your working directory can be in one of two states: tracked or untracked. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. +Recuerda que cada archivo de tu repositorio puede tener dos estados: rastreados y sin rastrear. +Los archivos rastreados (_tracked files_ en inglés) son todos aquellos archivos que estaban en la última instantánea del proyecto; pueden ser archivos sin modificar, modificados o preparados. +Los archivos sin rastrear son todos los demás - cualquier otro archivo en tu directorio de trabajo que no estaba en tu última instantánea y que no están en el área de preparación (_staging area_). +Cuando clonas por primera vez un repositorio, todos tus archivos estarán rastreados y sin modificar pues acabas de sacarlos y aun no han sido editados. -As you edit files, Git sees them as modified, because you've changed them since your last commit. -You stage these modified files and then commit all your staged changes, and the cycle repeats. +Mientras editas archivos, Git los ve como modificados, pues han sido cambiados desde su último _commit_. +Luego preparas estos archivos modificados y finalmente confirmas todos los cambios preparados, y repites el ciclo. -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] +.El ciclo de vida del estado de tus archivos. +image::images/lifecycle.png[El ciclo de vida del estado de tus archivos.] [[_checking_status]] -==== Checking the Status of Your Files +==== Revisando el Estado de tus Archivos -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +La herramienta principal para determinar qué archivos están en qué estado es el comando `git status`.(((git commands, status))) +Si ejecutas este comando inmediatamente después de clonar un repositorio, deberías ver algo como esto: [source,console] ---- @@ -27,14 +27,14 @@ On branch master nothing to commit, working directory clean ---- -This means you have a clean working directory – in other words, there are no tracked and modified files. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<<_git_branching>> will go over branches and references in detail. +Esto significa que tienes un directorio de trabajo limpio - en otras palabras, que no hay archivos rastreados y modificados. +Además, Git no encuentra ningún archivo sin rastrear, de lo contrario aparecerían listados aquí. +Finalmente, el comando te indicaa en cuál rama estás y te informa que no ha variado con respecto a la misma rama en el servidor. +Por ahora, la rama siempre será ``master'', que es la rama por defecto; no le prestaremos atención ahora. +<<_git_branching>> tratará en detalle las ramas y las referencias. -Let's say you add a new file to your project, a simple README file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: +Supongamos que añades un nuevo archivo a tu proyecto, un simpe README. +Si el archivo no existía antes, y ejecutas `git status`, verás el archivo sin rastrear de la siguiente manera: [source,console] ---- @@ -49,23 +49,23 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -You can see that your new README file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including README, so let's start tracking the file. +Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado ``Untracked files'' en la salida. +Sin rastrear significa que Git ve archivos que no tenías en la instantánea (_commit_) anterior. Git no los incluirá en tu próxima instantánea a menos que se lo indiques explícitamente. +Se comporta así para evitar incluir accidentamente archivos binarios o cualquier otro archivo que no quieras incluir. +Como tú si quieres incluir README, debes comenzar a rastrearlo. [[_tracking_files]] -==== Tracking New Files +==== Rastrear Archivos Nuevos -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the README file, you can run this: +Para comenzar a rastrear un archivo debes usar el comando `git add`.(((git commands, add))) +Para comenzar a rastrear el archivo README, puede ejecutar lo siguiente: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your README file is now tracked and staged to be committed: +Ahora si vuelves a ver el estado del proyecto, verás que el archivo README está siendo rastreado y está preparado para ser confirmado: [source,console] ---- @@ -78,15 +78,15 @@ Changes to be committed: ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add (files)` – that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +Puedes ver que está siendo rastreado porque aparece luego del encabezado ``Changes to be committed'' +Si confirmas en este punto, se guardará en el historial la versión del archivo correspondiente al instante en que ejecutaste `git add`. +Anteriormente cuando ejecutaste `git init`, ejecutaste luego `git add (files)` - lo cual inició el rastreo de archivos en tu directorio.(((git commands, init)))(((git commands, add))) +El comando `git add` puede recibir tanto una ruta de archivo como de un directorio; si es de un directorio, el comando añade recursivamente los archivos que están dentro de él. -==== Staging Modified Files +==== Preparar Archivos Modificados -Let's change a file that was already tracked. -If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this: +Vamos a cambiar un archivo que esté rastreado. +Si cambias el archivo rastreado llamado ``CONTRIBUTING.md'' y luego ejecutas el comando `git status`, verás algo parecido a esto: [source,console] ---- @@ -105,9 +105,9 @@ Changes not staged for commit: ---- -The ``CONTRIBUTING.md'' file appears under a section named ``Changed but not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again: +El archivo ``CONTRIBUTING.md'' aparece en una sección llamada ``Changed but not staged for commit'' - lo que significa que existe un archivo rastreado que ha sido modificado en el directorio de trabajo pero que aun no está preparado. +Para prepararlo, ejecutas el comando `git add`. `git add` es un comando que cumple varios propósitos - lo usas para empezar a rastrear archivos nuevos, preparar archivos, y hacer otras cosas como marcar como resuelto archivos en conflicto por combinación. Es más útil que lo veas como un comando para ``añadir este contenido a la próxima confirmación'' mas que para ``añadir este archivo al proyecto''.(((git commands, add))) +Ejecutemos `git add` para preparar el archivo ``CONTRIBUTING.md'' y luego ejecutemos `git status`: [source,console] ---- @@ -122,10 +122,10 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +Ambos archivos están preparados y formarán parte de tu próxima confirmación. +En este momento, supongamos que recuerdas que debes hacer un pequeño cambio en `CONTRIBUTING.md` antes de confirmarlo. +Abres de nuevo el archivo, lo cambias y ahora estás listos para confirmar. +Sin embargo, ejecutemos `git status` una vez más: [source,console] ---- @@ -146,12 +146,12 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +¡¿Pero qué...!? +Ahora `CONTRIBUTING.md` aparece como preparado y como no preparado. +¿Cómo es posible? +Resulta que Git prepara un archivo de acuerdo al estado que tenía cuando ejecutas el comando `git add`. +Si confirmas ahora, se confirmará la versión de `CONTRIBUTING.md` que tenías la última vez que ejecutaste `git add` y no la versión que ves ahora en tu directorio de trabajo al ejecutar `git commit`. +Si modificas un archivo luego de ejecutar `git add`, deberás ejecutar `git add` de nuevo para preparar la última versión del archivo: [source,console] ---- @@ -165,9 +165,9 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== Estatus Abreviado -While the `git status` output is pretty comprehensive, it's also quite wordy. Git also has a short status flag so you can see your changes in a more compact way. If you run `git status -s` or `git status --short` you get a far more simplified output from the command. +Si bien es cierto que la salida de `git status` es bastante explícita, también es verdad que es muy extensa. Git ofrece una opción para obtener un estatus abreviado, de manera que puedas ver tus cambios de una forma más compacta. Si ejecutas `git status -s` o `git status --short` obtendrás una salida mucho más simplificada. [source,console] ---- @@ -179,15 +179,14 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified. So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +Los archivos nuevos que no están rastreados tienen un `??` a su lado, los archivos que están preparados tienen una `A` y los modificados una `M`. El estado aparece en dos columnas - la columna de la izquierda indica el estado preparado y la columna de la derecha indica el estado sin preparar. Por ejemplo, en esa salida, el archivo `README` está modificado en el directorio de trabajo pero no está preparado, mientras que `lib/simplegit.rb` está modificado y preparado. El archivo `Rakefile` fue modificado, preparado y modificado otra vez por lo que existen cambios preparados y sin preparar. [[_ignoring]] -==== Ignoring Files +==== Ignorar Archivos -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +A veces, tendrás algún tipo de archivo que no quieres que Git añada automáticamente o más aun, que ni siquiera quieras que aparezcan como no rastreados. +Este suele ser el caso de archivos generados automáticamente como trazas o archivos creados por tu sistema de construcción. En estos casos, puedes crear un archivo llamado `.gitignore` que liste patrones a considerar.(((ignoring files))) +Este es un ejemplo de un archivo `.gitignore`: [source,console] ---- @@ -196,23 +195,23 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code. -The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +La primera línea le indica a Git que ignore cualquier archivo que termine en ``.o'' o ``.a'' - archivos de objeto o librerías que pueden ser producto de compilar tu código. +La segunda línea le indica a Git que ignore todos los archivos que termine con una tilde (`~`), lo cual es usado por varios editores de text como Emacs para marcar archivos temporales. +También puedes incluir cosas como trazas, temporales, o pid directamente; documentación generada automáticamente; etc. +Crear un archivo `.gitignore` antes de comenzar a trabajar es generalmente una buena idea pues así evitas confirmar accidentalmente archivos que en realidad no quieres incluir en tu repositorio Git. -The rules for the patterns you can put in the `.gitignore` file are as follows: +Las reglas sobre los patrones que puedes incluir en el archivo `.gitignore` son las siguientes: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* Ignorar las líneas en blanco y aquellas que comiencen con `#`. +* Aceptar patrones _glob_ estándar. +* Los patrones pueden terminar en barra (`/`) para especificar un directorio. +* Los patrones pueden negarse si se añade al principio el signo de exclamación (`!`). -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +Los patrones glob son una especia de expresión regular simplificada usada por los terminales. +Un asterisco (`*`) corresponde a cero o más caracteres; `[abc]` corresponde a cualquier caracter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (`?`) corresponde a un caracter cualquier; y los corchetes sobre caracteres separados por un guión (`[0-9]`) corresponde a cualquier caracter entre ellos (en este caso del 0 al 9). +También puedes usar dos asteriscos para indicat directorios anidados; `a/**/z` coincide con `a/z`, `a/b/z`, `a/b/c/z`, etc. -Here is another example .gitignore file: +Aquí puedes ver otro ejemplo de un archivo `.gitignore`: [source] ---- @@ -237,19 +236,18 @@ doc/**/*.txt [TIP] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +GitHub mantiene una extensa lista de archivos `.gitignore` adecuados a docenas de proyectos y lenguajes en https://github.com/github/gitignore[] en caso de que quieras tener un punto de partida para tu proyecto. ==== [[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +==== Ver los Cambios Preparados y No Preparados -If the `git status` command is too vague for you – you want to know exactly what you changed, not just which files were changed – you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed – the patch, as it were. +Si el comando `git status` es muy impreciso para ti - quieres ver exactamente que ha cambiado, no solo cuáles archivos lo han hecho - puedes usar el comando `git diff`.(((git commands, diff))) +Hablaremos sobre `git diff` más adelante, pero lo usarás probablemente para responder estas dos preguntas: ¿Qué has cambiado pero aun no has preparado? y ¿Qué has preparado y está listo para confirmar? +A pesar de que `git status` responde a estas preguntas de forma muy general listando el nombre de los archivos, `git diff` te muestra las líneas exactas que fueron añadidas y eliminadas, es decir, el parche. -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +Supongamos que editas y preparas el archivo `README` de nuevo y luego editas `CONTRIBUTING.md` pero no lo preparas. +Si ejecutas el comando `git status`, verás algo como esto: [source,console] ---- @@ -267,7 +265,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -To see what you've changed but not yet staged, type `git diff` with no other arguments: +Para ver qué has cambiado pero aun no has preparado, escribe `git diff` sin más parámetros: [source,console] ---- @@ -288,11 +286,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +Este comando compara lo que tienes en tu directorio de trabajo con lo que está en el área de preparación. +El resultado te indica los cambios que has hecho pero que aun no has preparado. -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +Si quieres ver lo que has preparado y será incluído en la próxima confirmación, puedes usar `git diff --staged`. +Este comando compara tus cambios preparados con la última instantánea confirmada. [source,console] ---- @@ -306,10 +304,10 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit – only changes that are still unstaged. -This can be confusing, because if you've staged all of your changes, `git diff` will give you no output. +Es importante resaltar que al llamar a `git diff` sin parámetros no verás los cambios desde tu última confirmación - solo verás los cambios que aun no están preparados. +Esto puede ser confuso porque si preparas todos tus cambios, `git diff` lo te devolverá ninguna salida. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. If our environment looks like this: +Pasemos a otro ejemplo, si preparas el archivo `CONTRIBUTING.md` y luego lo editas, puedes usar `git diff` para ver los cambios en el archivo que están preparados y los cambios que no lo están. Si nuestro ambiente es como este: [source,console] ---- @@ -329,7 +327,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged +Puedes usar `git diff` para ver qué está sin preparar [source,console] ---- @@ -345,7 +343,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (--staged and --cached are synonyms): +y `git diff --cached` para ver que has preparado hasta ahora (--staged y --cached son sinónimos): [source,console] ---- @@ -367,29 +365,30 @@ index 8ebb991..643e24f 100644 ---- [NOTE] -.Git Diff in an External Tool +.Git Diff como Herramienta Externa ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like Araxis, emerge, vimdiff and more. Run `git difftool --tool-help` to see what is available on your system. +A lo largo del libro, continuaremos usando el comando `git diff` de distintas maneras. Existe otra forma de ver estas diferencias si prefieres utilizar una interfaz gráfica u otro programa externo. Si ejecutas `git difftool` en vez de `git diff`, podrás ver los cambios con programas de este tipo como Araxis, emerge, vimdiff y más. Ejecuta `git difftool --tool-help` para ver qué tienes disponible en tu sistema. ==== [[_committing_changes]] -==== Committing Your Changes +==== Confirmar tus Cambios -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged – any files you have created or modified that you haven't run `git add` on since you edited them – won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) +Ahora que tu área de preparación está como quieres, puedes confirmar tus cambios. +Recuerda que cualquier cosa que no esté preparada - cualquier archivo que hayas creado o modificado y que no hayas agregado con `git add` desde su edición - no será confirmado. +Se mantendrán como archivos modificados en tu disco. +En este caso, digamos que la última vez que ejecutaste `git status` verificaste que todo estaba preparado y que estás listos para confirmar tus cambios.(((git commands, status))) +La forma más sencilla de confirmar es escribiendo `git commit`:(((git commands, commit))) [source,console] ---- $ git commit ---- -Doing so launches your editor of choice. -(This is set by your shell's `$EDITOR` environment variable – usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <<_getting_started>>).(((editor, changing default)))(((git commands, config))) +Al hacerlo, arrancará el editor de tu preferencia. +(El editor se establece a través de la variable de ambiente `$EDITOR` de tu terminal - usualmente es vim o emacs, aunque puedes configurarlo con el editor que quieras usando el comando ` +git config --global core.editor` tal como vista en <<_getting_started>>).(((editor, changing default)))(((git commands, config))) -The editor displays the following text (this example is a Vim screen): +El editor mostrará el siguiente texto (este ejemplo corresponde a una pantalla de Vim): [source] ---- @@ -407,13 +406,13 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +Puedes ver que el mensaje de confirmación por defecto contiene la última salida del comando `git status` comentada y una línea vacía encima de ella. +Puedes eliminar estos comentarios y escribir tu mensaje de confirmación, o puedes dejarlos allí para ayudarte a recordar qué estás confirmando. +(Para obtener una forma más explícita de recordar qué has modificado, puedes pasar la opción `-v` a `git commit`. +Al hacerlo se incluirá en el editor el diff de tus cambios para que veas exactamente qué cambios estás confirmando.) +Cuando sales del editor, Git crea tu confirmación con tu mensaje (eliminando el texto comentado y el diff). -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +Otra alternativa es escribir el mensaje de confirmación directamente en el comando `commit` utilizando la opción -m: [source,console] ---- @@ -423,19 +422,19 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +¡Has creado tu primera confirmación (_commit_)! +Puedes ver que la confirmación te devuelve una salida descriptiva: indica cuál rama as confirmado (`master`), que _checksum_ SHA-1 tiene el _commit_ (`463dc4f`), cuántos archivos han cambiado y estadísticas sobre las líneas añadidas y eliminadas en el _commit_. -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +Recuerda que la confirmación guarda una instantánea de tu área de preparación. +Todo lo que no hayas preparado sigue allí modificado; puedes hacer una nueva confirmación para añadirlo a tu historial. +Cada vez que realizas un _commit_, guardas una instantánea de tu proyecto la cual puedes usar para comparar o volver a ella luego. -==== Skipping the Staging Area +==== Saltar el Área de Preparación (((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +A pesar de que puede resultar muy útil para ajutar los _commits_ tal como quieres, el área de preparación es a veces un paso más complejo a lo que necesitas para tu flujo de trabajo. +Si quieres saltarte el área de preparación, Git te ofrece un atajo sencillo. +Añadiendo la opción `-a` al comando `git commit` harás que Git prepare automáticamente todos los archivos rastreados antes de confirmarlos, ahorrándote el paso de `git add`: [source,console] ---- @@ -453,16 +452,16 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit. +Fíjate que no fue necesario ejecutar `git add` sobre el archivo `CONTRIBUTING.md` en este caso antes de confirmar. [[_removing_files]] -==== Removing Files +==== Eliminar Archivos (((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. +Para eliminar archivos de Git, debes eliminarlos de tus archivos rastreados (o mejor dicho, eliminarlos del área de preparación) y luego confirmar. +Para ello existe el comando `git rm`, que además elimina el archivo de tu directorio de trabajo de manera que no aparezca la próxima vez como un archivo no rastreado. -If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output: +Si simplemente eliminas el archivo de tu directorio de trabajo, aparecerá en la sección ``Changed but not updated'' (esto es, _sin rastrear_) en la salida de `git status`: [source,console] ---- @@ -479,7 +478,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +Ahora, si ejecutas `git rm`, entonces se prepara la eliminación del archivo: [source,console] ---- @@ -493,58 +492,58 @@ Changes to be committed: deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file and added it to the index already, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +Con la próxima confirmación, el archivo habrá desaparecido y volverá a ser rastreado. +Si modificaste el archivo y ya lo habías añadido al índice, tendrás que forzar su eliminación con la opción `-f`. +Esta propiedad existe por seguridad, para prevenir que elimines accidentalmente datos que aun no han sido guardados como una instantánea y que por lo tanto no podrás recuperar luego con Git. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +Otra cosa que puedas querer hacer es mantener el archivo en el tu directorio de trabajo pero eliminarlo del área de preparación. +En otras palabras, quisieras mantener el archivo en tu disco duro pero sin que Git lo siga rastreando. +Esto puede ser particularmente útil si olvidaste añadir algo en tu archivo `.gitignore` y lo preparaste accidentalmente, algo como un gran archivo de trazas a un montón de archivos compilados `.a`. +Para hacerlo, utiliza la opción `--cached`: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as +Al comando `git rm` puedes pasarle archivos, directorios y patrones glob. +Lo que significa que puedes hacer cosas como [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +Fíjate en la barra invertida (`\`) antes del asterisco `*`. +Esto es necesario porque Git hace su propia expansión de nombres de archivo, aparte de la expansión hecho por tu terminal. +Este comando elimina todos los archivo que tengan la extensión `.log` dentro del directorio `log/`. +O también puedes hacer algo como: [source,console] ---- $ git rm \*~ ---- -This command removes all files that end with `~`. +Este comando elimina todos los archivos que acaben con `~`. [[_git_mv]] -==== Moving Files +==== Cambiar el Nombre de los Archivos (((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact – we'll deal with detecting file movement a bit later. +Al contrario que muchos sistemas VCS, Git no rastrea explícitamente los cambios de nombre en archivos. +Si renombras un archivo en Git, no se guardará ningún metadato que indique que renombraste el archivo. +Sin embargo, Git es bastante listo como para detectar estos cambios luego que lo has hecho - más adelante, veremos cómo se detecta el cambio de nombre. -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like +Por esto, resula confuso que Git tenga un comando `mv`. +Si quieres renombrar un archivo en Git, puedes ejecutar algo como [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +y funcionará bien. +De hecho, si ejecutas algo como eso y ver el estatus, verás que Git lo considera como un renombramiento de archivo: [source,console] ---- @@ -557,7 +556,7 @@ Changes to be committed: renamed: README.md -> README ---- -However, this is equivalent to running something like this: +Sin embargo, eso es equivalente a ejecutar algo como esto: [source,console] ---- @@ -566,6 +565,6 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `mv` is one command instead of three – it's a convenience function. -More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Git se da cuenta que es un renombramiento implícito, así que no importa si renombras el archivo de esa manera o a través del comando `mv`. +La única diferencia real es que `mv` es un solo comando en vez de tres - existe por conveniencia. +De hecho, puedes usar la herramienta que quieras para renombrar un archivo y luego realizar el proceso add/rm antes de confirmar. From ecdc6dec8c259470dfd3f3b7ff0b26133773bde6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 15:30:44 +0100 Subject: [PATCH 05/10] =?UTF-8?q?correcci=C3=B3n=20de=20errores=20ortogr?= =?UTF-8?q?=C3=A1ficos=20y=20de=20tipeo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../02-git-basics/sections/recording-changes.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index cf85e39e..07876908 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -29,11 +29,11 @@ nothing to commit, working directory clean Esto significa que tienes un directorio de trabajo limpio - en otras palabras, que no hay archivos rastreados y modificados. Además, Git no encuentra ningún archivo sin rastrear, de lo contrario aparecerían listados aquí. -Finalmente, el comando te indicaa en cuál rama estás y te informa que no ha variado con respecto a la misma rama en el servidor. +Finalmente, el comando te indica en cuál rama estás y te informa que no ha variado con respecto a la misma rama en el servidor. Por ahora, la rama siempre será ``master'', que es la rama por defecto; no le prestaremos atención ahora. <<_git_branching>> tratará en detalle las ramas y las referencias. -Supongamos que añades un nuevo archivo a tu proyecto, un simpe README. +Supongamos que añades un nuevo archivo a tu proyecto, un simple README. Si el archivo no existía antes, y ejecutas `git status`, verás el archivo sin rastrear de la siguiente manera: [source,console] @@ -51,7 +51,7 @@ nothing added to commit but untracked files present (use "git add" to track) Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado ``Untracked files'' en la salida. Sin rastrear significa que Git ve archivos que no tenías en la instantánea (_commit_) anterior. Git no los incluirá en tu próxima instantánea a menos que se lo indiques explícitamente. -Se comporta así para evitar incluir accidentamente archivos binarios o cualquier otro archivo que no quieras incluir. +Se comporta así para evitar incluir accidentalmente archivos binarios o cualquier otro archivo que no quieras incluir. Como tú si quieres incluir README, debes comenzar a rastrearlo. [[_tracking_files]] @@ -208,8 +208,8 @@ Las reglas sobre los patrones que puedes incluir en el archivo `.gitignore` son * Los patrones pueden negarse si se añade al principio el signo de exclamación (`!`). Los patrones glob son una especia de expresión regular simplificada usada por los terminales. -Un asterisco (`*`) corresponde a cero o más caracteres; `[abc]` corresponde a cualquier caracter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (`?`) corresponde a un caracter cualquier; y los corchetes sobre caracteres separados por un guión (`[0-9]`) corresponde a cualquier caracter entre ellos (en este caso del 0 al 9). -También puedes usar dos asteriscos para indicat directorios anidados; `a/**/z` coincide con `a/z`, `a/b/z`, `a/b/c/z`, etc. +Un asterisco (`*`) corresponde a cero o más caracteres; `[abc]` corresponde a cualquier carácter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (`?`) corresponde a un carácter cualquier; y los corchetes sobre caracteres separados por un guión (`[0-9]`) corresponde a cualquier carácter entre ellos (en este caso del 0 al 9). +También puedes usar dos asteriscos para indicar directorios anidados; `a/**/z` coincide con `a/z`, `a/b/z`, `a/b/c/z`, etc. Aquí puedes ver otro ejemplo de un archivo `.gitignore`: @@ -289,7 +289,7 @@ index 8ebb991..643e24f 100644 Este comando compara lo que tienes en tu directorio de trabajo con lo que está en el área de preparación. El resultado te indica los cambios que has hecho pero que aun no has preparado. -Si quieres ver lo que has preparado y será incluído en la próxima confirmación, puedes usar `git diff --staged`. +Si quieres ver lo que has preparado y será incluido en la próxima confirmación, puedes usar `git diff --staged`. Este comando compara tus cambios preparados con la última instantánea confirmada. [source,console] @@ -432,7 +432,7 @@ Cada vez que realizas un _commit_, guardas una instantánea de tu proyecto la cu ==== Saltar el Área de Preparación (((staging area, skipping))) -A pesar de que puede resultar muy útil para ajutar los _commits_ tal como quieres, el área de preparación es a veces un paso más complejo a lo que necesitas para tu flujo de trabajo. +A pesar de que puede resultar muy útil para ajustar los _commits_ tal como quieres, el área de preparación es a veces un paso más complejo a lo que necesitas para tu flujo de trabajo. Si quieres saltarte el área de preparación, Git te ofrece un atajo sencillo. Añadiendo la opción `-a` al comando `git commit` harás que Git prepare automáticamente todos los archivos rastreados antes de confirmarlos, ahorrándote el paso de `git add`: @@ -534,7 +534,7 @@ Al contrario que muchos sistemas VCS, Git no rastrea explícitamente los cambios Si renombras un archivo en Git, no se guardará ningún metadato que indique que renombraste el archivo. Sin embargo, Git es bastante listo como para detectar estos cambios luego que lo has hecho - más adelante, veremos cómo se detecta el cambio de nombre. -Por esto, resula confuso que Git tenga un comando `mv`. +Por esto, resulta confuso que Git tenga un comando `mv`. Si quieres renombrar un archivo en Git, puedes ejecutar algo como [source,console] From 0287bb9890f09e8992dc549f84500a6da93a059d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Thu, 5 Mar 2015 15:59:50 +0100 Subject: [PATCH 06/10] =?UTF-8?q?agregar=20menciones=20de=20traducci=C3=B3?= =?UTF-8?q?n=20y=20corregir=20errores=20menores?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/recording-changes.asc | 43 +++++++++---------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 07876908..5815e947 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -49,16 +49,16 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado ``Untracked files'' en la salida. -Sin rastrear significa que Git ve archivos que no tenías en la instantánea (_commit_) anterior. Git no los incluirá en tu próxima instantánea a menos que se lo indiques explícitamente. +Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado ``Untracked files'' (``Archivos no rastreados'' en inglés) en la salida. +Sin rastrear significa que Git ve archivos que no tenías en el _commit_ anterior. Git no los incluirá en tu próximo _commit_ a menos que se lo indiques explícitamente. Se comporta así para evitar incluir accidentalmente archivos binarios o cualquier otro archivo que no quieras incluir. -Como tú si quieres incluir README, debes comenzar a rastrearlo. +Como tú sí quieres incluir README, debes comenzar a rastrearlo. [[_tracking_files]] ==== Rastrear Archivos Nuevos Para comenzar a rastrear un archivo debes usar el comando `git add`.(((git commands, add))) -Para comenzar a rastrear el archivo README, puede ejecutar lo siguiente: +Para comenzar a rastrear el archivo README, puedes ejecutar lo siguiente: [source,console] ---- @@ -78,7 +78,7 @@ Changes to be committed: ---- -Puedes ver que está siendo rastreado porque aparece luego del encabezado ``Changes to be committed'' +Puedes ver que está siendo rastreado porque aparece luego del encabezado ``Changes to be committed'' (``Cambios a ser confirmados'' en inglés). Si confirmas en este punto, se guardará en el historial la versión del archivo correspondiente al instante en que ejecutaste `git add`. Anteriormente cuando ejecutaste `git init`, ejecutaste luego `git add (files)` - lo cual inició el rastreo de archivos en tu directorio.(((git commands, init)))(((git commands, add))) El comando `git add` puede recibir tanto una ruta de archivo como de un directorio; si es de un directorio, el comando añade recursivamente los archivos que están dentro de él. @@ -105,7 +105,7 @@ Changes not staged for commit: ---- -El archivo ``CONTRIBUTING.md'' aparece en una sección llamada ``Changed but not staged for commit'' - lo que significa que existe un archivo rastreado que ha sido modificado en el directorio de trabajo pero que aun no está preparado. +El archivo ``CONTRIBUTING.md'' aparece en una sección llamada ``Changes not staged for commit'' (``Cambios no preparado para confirmar'' en inglés) - lo que significa que existe un archivo rastreado que ha sido modificado en el directorio de trabajo pero que aun no está preparado. Para prepararlo, ejecutas el comando `git add`. `git add` es un comando que cumple varios propósitos - lo usas para empezar a rastrear archivos nuevos, preparar archivos, y hacer otras cosas como marcar como resuelto archivos en conflicto por combinación. Es más útil que lo veas como un comando para ``añadir este contenido a la próxima confirmación'' mas que para ``añadir este archivo al proyecto''.(((git commands, add))) Ejecutemos `git add` para preparar el archivo ``CONTRIBUTING.md'' y luego ejecutemos `git status`: @@ -146,7 +146,7 @@ Changes not staged for commit: ---- -¡¿Pero qué...!? +¡¿Pero qué...?! Ahora `CONTRIBUTING.md` aparece como preparado y como no preparado. ¿Cómo es posible? Resulta que Git prepara un archivo de acuerdo al estado que tenía cuando ejecutas el comando `git add`. @@ -184,7 +184,7 @@ Los archivos nuevos que no están rastreados tienen un `??` a su lado, los archi [[_ignoring]] ==== Ignorar Archivos -A veces, tendrás algún tipo de archivo que no quieres que Git añada automáticamente o más aun, que ni siquiera quieras que aparezcan como no rastreados. +A veces, tendrás algún tipo de archivo que no quieres que Git añada automáticamente o más aun, que ni siquiera quieras que aparezca como no rastreado. Este suele ser el caso de archivos generados automáticamente como trazas o archivos creados por tu sistema de construcción. En estos casos, puedes crear un archivo llamado `.gitignore` que liste patrones a considerar.(((ignoring files))) Este es un ejemplo de un archivo `.gitignore`: @@ -196,14 +196,14 @@ $ cat .gitignore ---- La primera línea le indica a Git que ignore cualquier archivo que termine en ``.o'' o ``.a'' - archivos de objeto o librerías que pueden ser producto de compilar tu código. -La segunda línea le indica a Git que ignore todos los archivos que termine con una tilde (`~`), lo cual es usado por varios editores de text como Emacs para marcar archivos temporales. +La segunda línea le indica a Git que ignore todos los archivos que termine con una tilde (`~`), lo cual es usado por varios editores de texto como Emacs para marcar archivos temporales. También puedes incluir cosas como trazas, temporales, o pid directamente; documentación generada automáticamente; etc. Crear un archivo `.gitignore` antes de comenzar a trabajar es generalmente una buena idea pues así evitas confirmar accidentalmente archivos que en realidad no quieres incluir en tu repositorio Git. Las reglas sobre los patrones que puedes incluir en el archivo `.gitignore` son las siguientes: * Ignorar las líneas en blanco y aquellas que comiencen con `#`. -* Aceptar patrones _glob_ estándar. +* Aceptar patrones glob estándar. * Los patrones pueden terminar en barra (`/`) para especificar un directorio. * Los patrones pueden negarse si se añade al principio el signo de exclamación (`!`). @@ -305,7 +305,7 @@ index 0000000..03902a1 ---- Es importante resaltar que al llamar a `git diff` sin parámetros no verás los cambios desde tu última confirmación - solo verás los cambios que aun no están preparados. -Esto puede ser confuso porque si preparas todos tus cambios, `git diff` lo te devolverá ninguna salida. +Esto puede ser confuso porque si preparas todos tus cambios, `git diff` no te devolverá ninguna salida. Pasemos a otro ejemplo, si preparas el archivo `CONTRIBUTING.md` y luego lo editas, puedes usar `git diff` para ver los cambios en el archivo que están preparados y los cambios que no lo están. Si nuestro ambiente es como este: @@ -385,8 +385,7 @@ $ git commit ---- Al hacerlo, arrancará el editor de tu preferencia. -(El editor se establece a través de la variable de ambiente `$EDITOR` de tu terminal - usualmente es vim o emacs, aunque puedes configurarlo con el editor que quieras usando el comando ` -git config --global core.editor` tal como vista en <<_getting_started>>).(((editor, changing default)))(((git commands, config))) +(El editor se establece a través de la variable de ambiente `$EDITOR` de tu terminal - usualmente es vim o emacs, aunque puedes configurarlo con el editor que quieras usando el comando `git config --global core.editor` tal como viste en <<_getting_started>>).(((editor, changing default)))(((git commands, config))) El editor mostrará el siguiente texto (este ejemplo corresponde a una pantalla de Vim): @@ -422,7 +421,7 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -¡Has creado tu primera confirmación (_commit_)! +¡Has creado tu primera confirmación (o _commit_)! Puedes ver que la confirmación te devuelve una salida descriptiva: indica cuál rama as confirmado (`master`), que _checksum_ SHA-1 tiene el _commit_ (`463dc4f`), cuántos archivos han cambiado y estadísticas sobre las líneas añadidas y eliminadas en el _commit_. Recuerda que la confirmación guarda una instantánea de tu área de preparación. @@ -452,7 +451,7 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Fíjate que no fue necesario ejecutar `git add` sobre el archivo `CONTRIBUTING.md` en este caso antes de confirmar. +Fíjate que en este caso no fue necesario ejecutar `git add` sobre el archivo `CONTRIBUTING.md` antes de confirmar. [[_removing_files]] ==== Eliminar Archivos @@ -461,7 +460,7 @@ Fíjate que no fue necesario ejecutar `git add` sobre el archivo `CONTRIBUTING.m Para eliminar archivos de Git, debes eliminarlos de tus archivos rastreados (o mejor dicho, eliminarlos del área de preparación) y luego confirmar. Para ello existe el comando `git rm`, que además elimina el archivo de tu directorio de trabajo de manera que no aparezca la próxima vez como un archivo no rastreado. -Si simplemente eliminas el archivo de tu directorio de trabajo, aparecerá en la sección ``Changed but not updated'' (esto es, _sin rastrear_) en la salida de `git status`: +Si simplemente eliminas el archivo de tu directorio de trabajo, aparecerá en la sección ``Changes not staged for commit'' (esto es, _sin preparar_) en la salida de `git status`: [source,console] ---- @@ -492,11 +491,11 @@ Changes to be committed: deleted: PROJECTS.md ---- -Con la próxima confirmación, el archivo habrá desaparecido y volverá a ser rastreado. +Con la próxima confirmación, el archivo habrá desaparecido y no volverá a ser rastreado. Si modificaste el archivo y ya lo habías añadido al índice, tendrás que forzar su eliminación con la opción `-f`. Esta propiedad existe por seguridad, para prevenir que elimines accidentalmente datos que aun no han sido guardados como una instantánea y que por lo tanto no podrás recuperar luego con Git. -Otra cosa que puedas querer hacer es mantener el archivo en el tu directorio de trabajo pero eliminarlo del área de preparación. +Otra cosa que puedas querer hacer es mantener el archivo en tu directorio de trabajo pero eliminarlo del área de preparación. En otras palabras, quisieras mantener el archivo en tu disco duro pero sin que Git lo siga rastreando. Esto puede ser particularmente útil si olvidaste añadir algo en tu archivo `.gitignore` y lo preparaste accidentalmente, algo como un gran archivo de trazas a un montón de archivos compilados `.a`. Para hacerlo, utiliza la opción `--cached`: @@ -515,7 +514,7 @@ $ git rm log/\*.log ---- Fíjate en la barra invertida (`\`) antes del asterisco `*`. -Esto es necesario porque Git hace su propia expansión de nombres de archivo, aparte de la expansión hecho por tu terminal. +Esto es necesario porque Git hace su propia expansión de nombres de archivo, aparte de la expansión hecha por tu terminal. Este comando elimina todos los archivo que tengan la extensión `.log` dentro del directorio `log/`. O también puedes hacer algo como: @@ -532,7 +531,7 @@ Este comando elimina todos los archivos que acaben con `~`. (((files, moving))) Al contrario que muchos sistemas VCS, Git no rastrea explícitamente los cambios de nombre en archivos. Si renombras un archivo en Git, no se guardará ningún metadato que indique que renombraste el archivo. -Sin embargo, Git es bastante listo como para detectar estos cambios luego que lo has hecho - más adelante, veremos cómo se detecta el cambio de nombre. +Sin embargo, Git es bastante listo como para detectar estos cambios luego que los has hecho - más adelante, veremos cómo se detecta el cambio de nombre. Por esto, resulta confuso que Git tenga un comando `mv`. Si quieres renombrar un archivo en Git, puedes ejecutar algo como @@ -543,7 +542,7 @@ $ git mv file_from file_to ---- y funcionará bien. -De hecho, si ejecutas algo como eso y ver el estatus, verás que Git lo considera como un renombramiento de archivo: +De hecho, si ejecutas algo como eso y ves el estatus, verás que Git lo considera como un renombramiento de archivo: [source,console] ---- @@ -567,4 +566,4 @@ $ git add README Git se da cuenta que es un renombramiento implícito, así que no importa si renombras el archivo de esa manera o a través del comando `mv`. La única diferencia real es que `mv` es un solo comando en vez de tres - existe por conveniencia. -De hecho, puedes usar la herramienta que quieras para renombrar un archivo y luego realizar el proceso add/rm antes de confirmar. +De hecho, puedes usar la herramienta que quieras para renombrar un archivo y luego realizar el proceso rm/add antes de confirmar. From 0011ec4ac064365c9f8e492d366f6ebf6bc6a41a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Fri, 6 Mar 2015 20:31:27 +0100 Subject: [PATCH 07/10] traducido remotes.asc --- book/02-git-basics/sections/remotes.asc | 116 ++++++++++++------------ 1 file changed, 58 insertions(+), 58 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index dc6d1ca7..268bd317 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,18 +1,18 @@ [[_remote_repos]] -=== Working with Remotes +=== Trabajar con Remotos -To be able to collaborate on any Git project, you need to know how to manage your remote repositories. -Remote repositories are versions of your project that are hosted on the Internet or network somewhere. -You can have several of them, each of which generally is either read-only or read/write for you. -Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. -Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. -In this section, we'll cover some of these remote-management skills. +Para poder colaborar en cualquier proyecto Git, necesitas saber cómo gestionar repositorios remotos. +Los repositorios remotos son versiones de tu proyecto que están hospedadas en Internet en cualquier otra red. +Puedes tener varios de ellos, y en cada uno tendrás generalmente permisos de solo lectura o de lectura y escritura. +Colaborar con otras personas implica gestionar estos repositorios remotos y enviar y traer datos de ellos cada vez que necesites compartir tu trabajo. +Gestionar repositorios remotos incluye saber cómo añadir un repositorio remoto, eliminar los remotos que ya no son válidos, gestionar varias ramas remotas y definir si deben rastrearse o no, y más. +En esta sección, trataremos algunas de estas habilidades de gestión de remotos. -==== Showing Your Remotes +==== Ver Tus Remotos -To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) -It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from: +Para ver los remotos que tienes configurados, debes ejecutar el comando `git remote`.(((git commands, remote))) +Mostrará los nombres de cada uno de los remotos que tienes especificados. +Si has clonado tu repositorio, deberías ver al menos _origin_ (origen, en inglés) - este es el nombre que por defecto Git le da al servidor del que has clonado: [source,console] ---- @@ -28,7 +28,7 @@ $ git remote origin ---- -You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: +También puedes pasar la opción `-v`, la cual muestra las URLs que Git ha asociado al nombre y que serán usadas al leer y escribir en ese remoto: [source,console] ---- @@ -37,8 +37,8 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -If you have more than one remote, the command lists them all. -For example, a repository with multiple remotes for working with several collaborators might look something like this. +Si tienes más de un remoto, el comando los listará todos. +Por ejemplo, un repositorio con múltiples remotos para trabajar con distintos colaboradores podría verse de la siguiente manera. [source,console] ---- @@ -56,14 +56,14 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here. +Esto significa que podemos traer contribuciones de cualquiera de estos usuarios fácilmente. Es posible que también tengamos permisos para enviar datos a algunos, aunque no podemos saberlo desde aquí. -Notice that these remotes use a variety of protocols; we'll cover more about this in <<_git_on_the_server>>. +Fíjate que estos remotos usan distintos protocolos; hablaremos sobre ello más adelante, en <<_git_on_the_server>>. -==== Adding Remote Repositories +==== Añadir Repositorios Remotos -We've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add [shortname] [url]`: +En secciones anteriores hemos mencionado y dado alguna demostración de cómo añadir repositorios remotos. Ahora veremos explícitamente cómo hacerlo.(((git commands, remote))) +Para añadir un remoto nuevo y asociarlo a un nombre que puedas referenciar fácilmente, ejecuta `git remote add [nombre] [url]`: [source,console] ---- @@ -77,8 +77,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +A partir de ahora puedes usar el nombre `pb` en la línea de comandos en lugar de la URL entera. +Por ejemplo, si quieres traer toda la información que tiene Paul pero tú aun no tienes en tu repositorio, puedes ejecutar `git fetch pb`: [source,console] ---- @@ -92,53 +92,53 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <<_git_branching>>.) +La rama maestra de Paul ahora es accesible localmente con el nombre `pb/master` - puedes combinarla con alguna de tus ramas, o puedes crear una rama local en ese punto si quieres inspeccionarla. +(Hablaremos con más detalle acerca de qué son las ramas y cómo utilizarlas en <<_git_branching>>.) [[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +==== Traer y Combinar Remotos -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +Como hemos visto hasta ahora, para obtener datos de tus proyectos remotos puedes ejecutar:(((git commands, fetch))) [source,console] ---- $ git fetch [remote-name] ---- -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +El comando irá al proyecto remoto y se traerá todos los datos que aun no tienes de dicho remoto. +Luego de hacer esto, tendrás referencias a todas las ramas del remoto, las cuales puedes combinar e inspeccionar cuando quieras. -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. +Si clonas un repositorio, el comando de clonar automáticamente añade ese repositorio remoto con el nombre ``origin''. +Por lo tanto, `git fetch origin` se trae todo el trabajo nuevo que ha sido enviado a ese servidor desde que lo clonaste (o desde la última vez que trajiste datos). +Es importante destacar que el comando `git fetch` solo trae datos a tu repositorio local - ni lo combina automáticamente con tu trabajo ni modifica el trabajo que llevas hecho. +La combinación con tu trabajo debes hacerla manualmente cuando estés listo. -If you have a branch set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +Si has configurado una rama para que rastree una rama remota (más información en la siguiente sección y en <<_git_branching>>), puedes usar el comando `git pull` para traer y combinar automáticamente la rama remota con tu rama actual.(((git commands, pull))) +Es posible que este sea un flujo de trabajo mucho más cómodo y fácil para ti; y por defecto, el comando `git clone` le indica automáticamente a tu rama maestra local que rastree la rama maestra remota (o como se llame la rama por defecto) del servidor del que has clonado. +Generalmente, al ejecutar `git pull` traerás datos del servidor del que clonaste originalmente y se intentará combinar automáticamente la información con el código en el que estás trabajando. [[_pushing_remotes]] -==== Pushing to Your Remotes +==== Enviar a Tus Remotos -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push [remote-name] [branch-name]`.(((git commands, push))) -If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +Cuando tienes un proyecto que quieres compartir, debes enviarlo a un servidor. +El comando para hacerlo es simple: `git push [nombre-remoto] [nombre-rama]`.(((git commands, push))) +Si quieres enviar tu rama `master` a tu servidor `origin` (recuerda, clonar un repositorio establece esos nombres automáticamente), entonces puedes ejecutar el siguiente comando y se enviarán todos los _commits_ que hayas hecho al servidor: [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push. -See <<_git_branching>> for more detailed information on how to push to remote servers. +Este comando solo funciona si clonaste de un servidor sobre el que tienes permisos de escritura y si nadie más ha enviado datos por el medio. +Si alguien más clona el mismo repositorio que tú y envía información antes que tú, tu envío será rechazado. +Tendrás que traerte su trabajo y combinarlo con el tuyo antes de que puedas enviar datos al servidor. +Para información más detallada sobre cómo enviar datos a servidores remotos, véase <<_git_branching>>. [[_inspecting_remote]] -==== Inspecting a Remote +==== Inspeccionar un Remoto -If you want to see more information about a particular remote, you can use the `git remote show [remote-name]` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +Si quieres ver más información acerca de un remoto en particular, puedes ejecutar el comando `git remote show [nombre-remoto]`.(((git commands, remote))) +Si ejecutas el comando con un nombre en particular, como `origin`, verás algo como lo siguiente: [source,console] ---- @@ -156,12 +156,12 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. +El comando lista la URL del repositorio remoto y la información del rastreo de ramas. +El comando te indica claramente que si estás en la rama maestra y ejecutas el comando `git pull`, automáticamente combinará la rama maestra remota luego de haber traído toda la información de ella. +También lista todas las referencias remotas de las que ha traído datos. -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +Ejemplos como este son los que te encontrarás normalmente. +Sin embargo, si usas Git de forma más avanzada, puede que obtengas mucha más información de un `git remote show`: [source,console] ---- @@ -187,13 +187,13 @@ $ git remote show origin master pushes to master (up to date) ---- -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`. +Este comando te indica a cuál rama enviarás información automáticamente cada vez que ejecutas `git push`, dependiendo de la rama en la que estés. +También te muestra cuáles ramas remotas no tienes aun, cuáles ramas remotas tienes que han sido eliminadas del servidor, y varias ramas que serán combinadas automáticamente cuando ejecutes `git pull`. -==== Removing and Renaming Remotes +==== Eliminar y Renombrar Remotos -If you want to rename a reference you can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +Si quieres cambiar el nombre de la referencia de un remoto puedes ejecutar `git remote rename`.(((git commands, remote))) +Por ejemplo, si quieres cambiar el nombre de `pb` a `paul`, puedes hacerlo con `git remote rename`: [source,console] ---- @@ -203,10 +203,10 @@ origin paul ---- -It's worth mentioning that this changes your remote branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. +Es importante destacar que al hacer esto también cambias el nombre de las ramas remotas. +Por lo tanto, lo que antes estaba referenciado como `pb/master` ahora lo está como `paul/master`. -If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can use `git remote rm`: +Si por alguna razón quieres eliminar un remoto - has cambiado de servidor o no quieres seguir utilizando un _mirror_, o quizás un colaborador a dejado de trabajar en el proyecto - puedes usar `git remote rm`: [source,console] ---- From 1352777983f6baed17c19a5134e2a1b760692a69 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Fri, 6 Mar 2015 21:11:23 +0100 Subject: [PATCH 08/10] traducido tagging.asc --- book/02-git-basics/sections/tagging.asc | 96 ++++++++++++------------- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 980ab004..a9e63dad 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,15 +1,15 @@ [[_git_tagging]] -=== Tagging +=== Etiquetado (((tags))) -Like most VCSs, Git has the ability to tag specific points in history as being important. -Typically people use this functionality to mark release points (v1.0, and so on). -In this section, you'll learn how to list the available tags, how to create new tags, and what the different types of tags are. +Como muchos VCS, Git tiene la posibilidad de etiquetar puntos específicos del historial como importantes. +Esta funcionalidad se usa típicamente para marcar versiones de lanzamiento (v1.0, por ejemplo). +En esta sección, aprenderás cómo listar las etiquetas disponibles, cómo crear nuevas etiquetas y cuáles son los distintos tipos de etiquetas. -==== Listing Your Tags +==== Listar Tus Etiquetas -Listing the available tags in Git is straightforward. -Just type `git tag`:(((git commands, tag))) +Listar las etiquetas disponibles en Git es sencillo. +Simplemente escribe `git tag`:(((git commands, tag))) [source,console] ---- @@ -18,11 +18,11 @@ v0.1 v1.3 ---- -This command lists the tags in alphabetical order; the order in which they appear has no real importance. +Este comando lista las etiquetas en orden alfabético; el orden en el que aparecen no tiene mayor importancia. -You can also search for tags with a particular pattern. -The Git source repo, for instance, contains more than 500 tags. -If you're only interested in looking at the 1.8.5 series, you can run this: +También puedes buscar etiquetas con un patrón particular. +El repositorio del código fuente de Git, por ejemplo, contiene más de 500 etiquetas. +Si solo te interesa ver la serie 1.8.5, puedes ejecutar: [source,console] ---- @@ -39,22 +39,22 @@ v1.8.5.4 v1.8.5.5 ---- -==== Creating Tags +==== Crear Etiquetas -Git uses two main types of tags: lightweight and annotated. +Git utiliza dos tipos principales de etiquetas: ligeras y anotadas. -A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit. +Una etiqueta ligera es muy parecido a una rama que no cambia - simplemente es un puntero a un _commit_ específico. -Annotated tags, however, are stored as full objects in the Git database. -They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). -It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. +Sin embargo, las etiquetas anotadas se guardan en la base de datos de Git como objetos enteros. +Tienen un _checksum_; contienen el nombre del etiquetador, correo electrónico y fecha; tienen un mensaje asociado; y pueden ser firmadas y verificadas con _GNU Privacy Guard_ (GPG). +Normalmente se recomienda que crees etiquetas anotadas, de manera que tengas toda esta información; pero si quieres una etiqueta temporal o por alguna razón no estás interesado en esa información, entonces puedes usar las etiquetas ligeras. [[_annotated_tags]] -==== Annotated Tags +==== Etiquetas Anotadas (((tags, annotated))) -Creating an annotated tag in Git is simple. -The easiest way is to specify `-a` when you run the `tag` command:(((git commands, tag))) +Crear una etiqueta anotada en Git es sencillo. +La forma más fácil de hacer es especificar la opción `-a` cuando ejecutas el comando `tag`:(((git commands, tag))) [source,console] ---- @@ -65,10 +65,10 @@ v1.3 v1.4 ---- -The `-m` specifies a tagging message, which is stored with the tag. -If you don't specify a message for an annotated tag, Git launches your editor so you can type it in. +La opción `-m` especifica el mensaje de la etiqueta, el cual es guardado junto con ella. +Si no especificas el mensaje de una etiqueta anotada, Git abrirá el editor de texto para que lo escribas. -You can see the tag data along with the commit that was tagged by using the `git show` command: +Puedes ver la información de la etiqueta junto con el _commit_ que está etiquetado al usar el comando `git show`: [source,console] ---- @@ -86,14 +86,14 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. +El comando muestra la información del etiquetador, la fecha en la que el _commit_ fue etiquetado y el mensaje de la etiquetar, antes de mostrar la información del _commit_. -==== Lightweight Tags +==== Etiquetas Ligeras (((tags, lightweight))) -Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file – no other information is kept. -To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option: +La otra forma de etiquetar un _commit_ es mediante una etiqueta ligera. +Una etiqueta ligera no es más que el _checksum_ de un _commit_ guardado en un archivo - no incluye más información. +Para crear una etiqueta ligera, no pases las opciones `-a`, `-s` ni `-m`: [source,console] ---- @@ -106,8 +106,8 @@ v1.4-lw v1.5 ---- -This time, if you run `git show` on the tag, you don't see the extra tag information.(((git commands, show))) -The command just shows the commit: +Esta vez, si ejecutas `git show` sobre la etiqueta, no verás la información adicional.(((git commands, show))) +El comando solo mostrará el _commit_: [source,console] ---- @@ -119,10 +119,10 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -==== Tagging Later +==== Etiquetado Tardío -You can also tag commits after you've moved past them. -Suppose your commit history looks like this: +También puedes etiquetar _commits_ mucho tiempo después de haberlos hecho. +Supongamos que tu historial luce como el siguiente: [source,console] ---- @@ -139,16 +139,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- -Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit. -You can add it after the fact. -To tag that commit, you specify the commit checksum (or part of it) at the end of the command: +Ahora, supongamos que olvidaste etiquetar el proyecto en su versión v1.2, la cual corresponde al _commit_ ``updated rakefile''. +Igual puedes etiquetarlo. +Para etiquetar un commit, debes especificar el _checksum_ del _commit_ (o parte de él) al final del comando: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -You can see that you've tagged the commit:(((git commands, tag))) +Puedes ver que has etiquetado el commit:(((git commands, tag))) [source,console] ---- @@ -175,11 +175,11 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== Sharing Tags +==== Compartir Etiquetas -By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) -You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches – you can run `git push origin [tagname]`. +Por defecto, el comando `git push` no transfiere las etiquetas a los servidores remotos.(((git commands, push))) +Debes enviar las etiquetas de forma explícita al servidor luego de que las hayas creado. +Este proceso es similar al de compartir ramas remotas - puede ejecutar `git push origin [etiqueta]`. [source,console] ---- @@ -193,8 +193,8 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. -This will transfer all of your tags to the remote server that are not already there. +Si quieres enviar varias etiquetas a la vez, puedes usar la opción `--tags` del comando `git push`. +Esto enviará al servidor remoto todas las etiquetas que aun no existen en él. [source,console] ---- @@ -207,12 +207,12 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Now, when someone else clones or pulls from your repository, they will get all your tags as well. +Por lo tanto, cuando alguien clone o traiga información de tu repositorio, también obtendrá todas las etiquetas. -==== Checking out Tags +==== Sacar una Etiqueta -You can't really check out a tag in Git, since they can't be moved around. -If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag: +En Git, no puedes sacar (_check out_) una etiqueta, pues no es algo que puedas mover. +Si quieres colocar en tu directorio de trabajo una versión de tu repositorio que coincida con alguna etiqueta, debes crear una rama nueva en esa etiqueta: [source,console] ---- @@ -220,4 +220,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Of course if you do this and do a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +Obviamente, si haces esto y luego confirmas tus cambios, tu rama `version2` será ligeramente distinta a tu etiqueta `v2.0.0` puesto que incluirá tus nuevos cambios; así que ten cuidado. From 5d7007dddf6ea547b02a5923b40a297418581634 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Fri, 6 Mar 2015 22:07:47 +0100 Subject: [PATCH 09/10] traducido undoing.asc --- book/02-git-basics/sections/undoing.asc | 78 ++++++++++++------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 8f468bc3..2ca6eb2f 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_undoing]] -=== Undoing Things +=== Deshacer Cosas -At any stage, you may want to undo something. -Here, we'll review a few basic tools for undoing changes that you've made. -Be careful, because you can't always undo some of these undos. -This is one of the few areas in Git where you may lose some work if you do it wrong. +En cualquier momento puede que quieras deshacer algo. +Aquí repasaremos algunas herramientas básicas usadas para deshacer cambios que hayas hecho. +Ten cuidado, a veces no es posible recuperar algo luego que lo has deshecho. +Esta es una de las pocas áreas en las que Git puede perder parte de tu trabajo si cometes un error. -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to try that commit again, you can run commit with the `--amend` option: +Uno de las acciones más comunes a deshacer es cuando confirmas un cambio antes de tiempo y olvidas agregar algún archivo, o te equivocas en el mensaje de confirmación. +Si quieres rehacer la confirmación, puedes reconfirmar con la opción `--amend`: [source,console] ---- $ git commit --amend ---- -This command takes your staging area and uses it for the commit. -If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. +Este comando utiliza tu área de preparación para la confirmación. +Si no has hecho cambios desde tu última confirmación (por ejemplo, ejecutas este comando justo después de tu confirmación anterior), entonces la instantánea lucirá exactamente igual, y lo único que cambiarás será el mensaje de confirmación. -The same commit-message editor fires up, but it already contains the message of your previous commit. -You can edit the message the same as always, but it overwrites your previous commit. +Se lanzará el mismo editor de confirmación, pero verás que ya incluye el mensaje de tu confirmación anterior. +Puedes editar el mensaje como siempre y se sobreescribirá tu confirmación anterior. -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +Por ejemplo, si confirmas y luego te das cuenta que olvidaste preparar los cambios de un archivo que querías incluir en esta confirmación, puedes hacer lo siguiente: [source,console] ---- @@ -29,16 +29,16 @@ $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit – the second commit replaces the results of the first. +Al final terminarás con una sola confirmación - la segunda confirmación reemplaza el resultado de la primera. [[_unstaging]] -==== Unstaging a Staged File +==== Deshacer un Archivo Preparado -The next two sections demonstrate how to wrangle your staging area and working directory changes. -The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. -For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. -How can you unstage one of the two? -The `git status` command reminds you: +Las siguientes dos secciones demuestran cómo lidiar con los cambios de tu área de preparación y tú directorio de trabajo. +Afortunadamente, el comando que usas para determinar el estado de esas dos áreas también te recuerda cómo deshacer los cambios en ellas. +Por ejemplo, supongamos que has cambiado dos archivos y que quieres confirmarlos como dos cambios separados, pero accidentalmente has escrito `git add *` y has preparado ambos. +¿Cómo puedes sacar del área de preparación uno de ellos? +El comando `git status` te recuerda cómo: [source,console] ---- @@ -52,8 +52,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -Right below the ``Changes to be committed'' text, it says use `git reset HEAD ...` to unstage. -So, let's use that advice to unstage the `CONTRIBUTING.md` file: +Justo debajo del texto ``Changes to be committed'' (``Cambios a ser confirmados'', en inglés), verás que dice que uses `git reset HEAD ...` para deshacer la preparación. +Por lo tanto, usemos el consejo para deshacer la preparación del archivo `CONTRIBUTING.md`: [source,console] ---- @@ -74,22 +74,22 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -The command is a bit strange, but it works. -The `CONTRIBUTING.md` file is modified but once again unstaged. +El comando es un poco raro, pero funciona. +El archivo `CONTRIBUTING.md` esta modificado y, nuevamente, no preparado. [NOTE] ===== -While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area. +A pesar de que `git reset` _puede_ ser un comando peligroso si lo llamas con `--hard`, en este caso el archivo que está en tu directorio de trabajo no se toca. Ejecutar `git reset` sin opciones no es peligroso - solo toca el área de preparación. ===== -For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_reset>>. +Por ahora lo único que necesitas saber sobre el comando `git reset` es esta invocación mágica. Entraremos en mucho más detalle sobre qué hace `reset` y como dominarlo para que haga cosas realmente interesantes en <<_git_reset>>. -==== Unmodifying a Modified File +==== Deshacer un Archivo Modificado -What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it – revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? -Luckily, `git status` tells you how to do that, too. -In the last example output, the unstaged area looks like this: +¿Qué tal si te das cuenta que no quieres mantener los cambios del archivo `CONTRIBUTING.md`? +¿Cómo puedes restaurarlo fácilmente - volver al estado en el que estaba en la última confirmación (o cuando estaba recién clonado, o como sea que haya llegado a tu directorio de trabajo)? +Afortunadamente, `git status` también te dice cómo hacerlo. +En la salida anterior, el área no preparada lucía así: [source,console] ---- @@ -100,8 +100,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -It tells you pretty explicitly how to discard the changes you've made. -Let's do what it says: +Allí se te indica explícitamente como descartar los cambios que has hecho. +Hagamos lo que nos dice: [source,console] ---- @@ -115,16 +115,16 @@ Changes to be committed: ---- -You can see that the changes have been reverted. +Ahora puedes ver que los cambios se han revertido. [IMPORTANT] ===== -It's important to understand that `git checkout -- [file]` is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. -Don't ever use this command unless you absolutely know that you don't want the file. +Es importante entender que `git checkout -- [archivo]` es un comando peligroso. Cualquier cambio que le hayas hecho a ese archivo desaparecerá - acabas de sobreescribirlo con otro archivo. +Nunca utilices este comando a menos que estés absolutamente seguro de que ya no quieres el archivo. ===== -If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<_git_branching>>; these are generally better ways to go. +Para mantener los cambios que has hecho y a la vez deshacerte del archivo temporalmente, hablaremos sobre cómo esconder archivos (_stashing_, en inglés) y sobre ramas en <<_git_branching>>; normalmente, estas son las mejores maneras de hacerlo. -Remember, anything that is __committed__ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<_data_recovery>> for data recovery). -However, anything you lose that was never committed is likely never to be seen again. +Recuerda, todo lo que esté __confirmado__ en Git puede recuperarse. +Incluso _commits_ que estuvieron en ramas que han sido eliminadas o _commits_ que fueron sobreescritos con `--amend` pueden recuperarse (véase <<_data_recovery>> para recuperación de datos). +Sin embargo, es posible que no vuelvas a ver jamás cualquier cosa que pierdas y que nunca haya sido confirmada. From 2a47000d9bced9a3cf3fac5f2086e40afc749772 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20A=2E=20Henri=CC=81quez=20Q?= Date: Sun, 8 Mar 2015 14:12:19 +0100 Subject: [PATCH 10/10] =?UTF-8?q?traducido=20viewing-history.asc=20usando?= =?UTF-8?q?=20la=20traducci=C3=B3n=20de=20progit=20v1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/viewing-history.asc | 178 +++++++++--------- 1 file changed, 88 insertions(+), 90 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 2ea68fe7..befcc1b1 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ [[_viewing_history]] -=== Viewing the Commit History +=== Ver el Historial de Confirmaciones -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. +Después de haber hecho varias confirmaciones, o si has clonado un repositorio que ya tenía un histórico de confirmaciones, probablemente quieras mirar atrás para ver qué modificaciones se han llevado a cabo. +La herramienta más básica y potente para hacer esto es el comando `git log`. -These examples use a very simple project called ``simplegit''. -To get the project, run +Estos ejemplos usan un proyecto muy sencillo llamado ``simplegit''. +Para clonar el proyecto, ejecuta: [source,console] ---- git clone https://github.com/schacon/simplegit-progit ---- -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +Cuando ejecutes `git log` sobre este proyecto, deberías ver una salida similar a esta:(((git commands, log))) [source,console] ---- @@ -36,14 +36,14 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order – that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and e-mail, the date written, and the commit message. +Por defecto, si no pasas ningún parámetro, `git log` lista las confirmaciones hechas sobre ese repositorio en orden cronológico inverso. +Es decir, las confirmaciones más recientes se muestran al principio. +Como puedes ver, este comando lista cada confirmación con su suma de comprobación SHA-1, el nombre y dirección de correo del autor, la fecha y el mensaje de confirmación. -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. +El comando `git log` proporciona gran cantidad de opciones para mostrarte exactamente lo que buscas. +Aquí veremos algunas de las más usadas. -One of the more helpful options is `-p`, which shows the difference introduced in each commit. -You can also use `-2`, which limits the output to only the last two entries: +Una de las opciones más útiles es `-p`, que muestra las diferencias introducidas en cada confirmación. También puedes usar la opción `-2`, que hace que se muestren únicamente las dos últimas entradas del historial: [source,console] ---- @@ -90,10 +90,10 @@ index a0a60ae..47c6340 100644 \ No newline at end of file ---- -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +Esta opción muestra la misma información, pero añadiendo tras cada entrada las diferencias que le corresponden. +Esto resulta muy útil para revisiones de código, o para visualizar rápidamente lo que ha pasado en las confirmaciones enviadas por un colaborador. +También puedes usar con `git log` una serie de opciones de resumen. +Por ejemplo, si quieres ver algunas estadísticas de cada confirmación, puedes usar la opción `--stat`: [source,console] ---- @@ -128,14 +128,12 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. +Como puedes ver, la opción `--stat` imprime tras cada confirmación una lista de archivos modificados, indicando cuántos han sido modificados y cuántas líneas han sido añadidas y eliminadas para cada uno de ellos, y un resumen de toda esta información. -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +Otra opción realmente útil es `--pretty`, que modifica el formato de la salida. +Tienes unos cuantos estilos disponibles. +La opción `oneline` imprime cada confirmación en una única línea, lo que puede resultar útil si estás analizando gran cantidad de confirmaciones. +Otras opciones son `short`, `full` y `fuller`, que muestran la salida en un formato parecido, pero añadiendo menos o más información, respectivamente: [source,console] ---- @@ -145,8 +143,8 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing – because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +La opción más interesante es `format`, que te permite especificar tu propio formato. +Esto resulta especialmente útil si estás generando una salida para que sea analizada por otro programa —como especificas el formato explícitamente, sabes que no cambiará en futuras actualizaciones de Git—:(((log formatting))) [source,console] ---- @@ -156,37 +154,37 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> lists some of the more useful options that format takes. +<> lista algunas de las opciones más útiles aceptadas por `format`. [[pretty_format]] -.Useful options for `git log --pretty=format` +.Opciones útiles de `git log --pretty=format` [cols="1,4",options="header"] |================================ -| Option | Description of Output -| `%H` | Commit hash -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author e-mail -| `%ad` | Author date (format respects the –date= option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject +| Opción | Descripción de la salida +| `%H` | Hash de la confirmación +| `%h` | Hash de la confirmación abreviado +| `%T` | Hash del árbol +| `%t` | Hash del árbol abreviado +| `%P` | Hashes de las confirmaciones padre +| `%p` | Hashes de las confirmaciones padre abreviados +| `%an` | Nombre del autor +| `%ae` | Dirección de correo del autor +| `%ad` | Fecha de autoría (el formato respeta la opción `-–date`) +| `%ar` | Fecha de autoría, relativa +| `%cn` | Nombre del confirmador +| `%ce` | Dirección de correo del confirmador +| `%cd` | Fecha de confirmación +| `%cr` | Fecha de confirmación, relativa +| `%s` | Asunto |================================ -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit – you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <<_distributed_git>>. +Puede que te estés preguntando la diferencia entre _autor_ (_author_) y _confirmador_ (_committer_). +El autor es la persona que escribió originalmente el trabajo, mientras que el confirmador es quien lo aplicó. +Por tanto, si mandas un parche a un proyecto, y uno de sus miembros lo aplica, ambos recibiréis reconocimiento —tú como autor, y el miembro del proyecto como confirmador—. +Veremos esta distinción en mayor profundidad en <<_distributed_git>>. -The oneline and format options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: +Las opciones `oneline` y `format` son especialmente útiles combinadas con otra opción llamada `--graph`. +Ésta añade un pequeño gráfico ASCII mostrando tu historial de ramificaciones y uniones: [source,console] ---- @@ -203,76 +201,76 @@ $ git log --pretty=format:"%h %s" --graph * 11d191e Merge branch 'defunkt' into local ---- -This type of output will become more interesting as we go through branching and merging in the next chapter. +Este tipo de salidas serán más interesantes cuando empecemos a hablar sobre ramificaciones y combinaciones en el próximo capítulo. -Those are only some simple output-formatting options to `git log` – there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +Éstas son sólo algunas de las opciones para formatear la salida de `git log` —existen muchas más. +<> lista las opciones vistas hasta ahora, y algunas otras opciones de formateo que pueden resultarte útiles, así como su efecto sobre la salida. [[log_options]] -.Common options to `git log` +.Opciones típicas de `git log` [cols="1,4",options="header"] |================================ -| Option | Description -| `-p` | Show the patch introduced with each commit. -| `--stat` | Show statistics for files modified in each commit. -| `--shortstat` | Display only the changed/insertions/deletions line from the --stat command. -| `--name-only` | Show the list of files modified after the commit information. -| `--name-status` | Show the list of files affected with added/modified/deleted information as well. -| `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40. -| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. -| `--graph` | Display an ASCII graph of the branch and merge history beside the log output. -| `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). +| Opción | Descripción +| `-p` | Muestra el parche introducido en cada confirmación. +| `--stat` | Muestra estadísticas sobre los archivos modificados en cada confirmación. +| `--shortstat` | Muestra solamente la línea de resumen de la opción `--stat`. +| `--name-only` | Muestra la lista de archivos afectados. +| `--name-status` | Muestra la lista de archivos afectados, indicando además si fueron añadidos, modificados o eliminados. +| `--abbrev-commit` | Muestra solamente los primeros caracteres de la suma SHA-1, en vez de los 40 caracteres de que se compone. +| `--relative-date` | Muestra la fecha en formato relativo (por ejemplo, “2 weeks ago” (“hace 2 semanas”)) en lugar del formato completo. +| `--graph` | Muestra un gráfico ASCII con la historia de ramificaciones y uniones. +| `--pretty` | Muestra las confirmaciones usando un formato alternativo. Posibles opciones son oneline, short, full, fuller y format (mediante el cual puedes especificar tu propio formato). |================================ -==== Limiting Log Output +==== Limitar la Salida del Historial -In addition to output-formatting options, `git log` takes a number of useful limiting options – that is, options that let you show only a subset of commits. -You've seen one such option already – the `-2` option, which show only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +Además de las opciones de formateo, `git log` acepta una serie de opciones para limitar su salida —es decir, opciones que te permiten mostrar únicamente parte de las confirmaciones—. +Ya has visto una de ellas, la opción `-2`, que muestra sólo las dos últimas confirmaciones. +De hecho, puedes hacer `-`, siendo `n` cualquier entero, para mostrar las últimas `n` confirmaciones. +En realidad es poco probable que uses esto con frecuencia, ya que Git por defecto pagina su salida para que veas cada página del historial por separado. -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: +Sin embargo, las opciones temporales como `--since` (desde) y `--until` (hasta) sí que resultan muy útiles. +Por ejemplo, este comando lista todas las confirmaciones hechas durante las dos últimas semanas: [source,console] ---- $ git log --since=2.weeks ---- -This command works with lots of formats – you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +Este comando acepta muchos formatos. Puedes indicar una fecha concreta (`"2008-01-15"`), o relativa, como `"2 years 1 day 3 minutes ago"` (`"hace 2 años, 1 día y 3 minutos"`). -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. -(Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +También puedes filtrar la lista para que muestre sólo aquellas confirmaciones que cumplen ciertos criterios. +La opción `--author` te permite filtrar por autor, y `--grep` te permite buscar palabras clave entre los mensajes de confirmación. +(Ten en cuenta que si quieres aplicar ambas opciones simultáneamente, tienes que añadir `--all-match`, o el comando mostrará las confirmaciones que cumplan cualquiera de las dos, no necesariamente las dos a la vez.) -Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string. For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +Otra opción útil es `-S`, la cual recibe una cadena y solo muestra las confirmaciones que cambiaron el código añadiendo o eliminando la cadena. +Por ejemplo, si quieres encontrar la última confirmación que añadió o eliminó una referencia a una función específica, puede ejecutar: [source,console] ---- $ git log -Sfunction_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +La última opción verdaderamente útil para filtrar la salida de `git log` es especificar una ruta. +Si especificas la ruta de un directorio o archivo, puedes limitar la salida a aquellas confirmaciones que introdujeron un cambio en dichos archivos. +Ésta debe ser siempre la última opción, y suele ir precedida de dos guiones (`--`) para separar la ruta del resto de opciones. -In <> we'll list these and a few other common options for your reference. +En <> se listan estas opciones, y algunas otras bastante comunes, a modo de referencia. [[limit_options]] -.Options to limit the output of `git log` +.Opciones para limitar la salida de `git log` [cols="2,4",options="header"] |================================ -| Option | Description -| `-(n)` | Show only the last n commits -| `--since`, `--after` | Limit the commits to those made after the specified date. -| `--until`, `--before` | Limit the commits to those made before the specified date. -| `--author` | Only show commits in which the author entry matches the specified string. -| `--committer` | Only show commits in which the committer entry matches the specified string. -| `--grep` | Only show commits with a commit message containing the string -| `-S` | Only show commits adding or removing code matching the string +| Opción | Descripción +| `-(n)` | Muestra solamente las últimas n confirmaciones +| `--since, --after` | Muestra aquellas confirmaciones hechas después de la fecha especificada. +| `--until, --before` | Muestra aquellas confirmaciones hechas antes de la fecha especificada. +| `--author` | Muestra solo aquellas confirmaciones cuyo autor coincide con la cadena especificada. +| `--committer` | Muestra solo aquellas confirmaciones cuyo confirmador coincide con la cadena especificada. +| `-S` | Muestra solo aquellas confirmaciones que añadan o eliminen código que corresponda con la cadena especificada. |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:(((log filtering))) +Por ejemplo, si quieres ver cuáles de las confirmaciones hechas sobre archivos de prueba del código fuente de Git fueron enviadas por Junio Hamano, y no fueron uniones, en el mes de octubre de 2008, ejecutarías algo así:(((log filtering))) [source,console] ---- @@ -286,4 +284,4 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +De las casi 40.000 confirmaciones en la historia del código fuente de Git, este comando muestra las 6 que cumplen estas condiciones.