From f75ef1967b1fd4345339e7183309bc53cc2b7737 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Mon, 10 Jul 2017 12:07:54 +0200 Subject: [PATCH 01/11] Update 1-introduction.asc --- book/01-introduction/1-introduction.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/1-introduction.asc b/book/01-introduction/1-introduction.asc index 12eef49a..6d19a193 100644 --- a/book/01-introduction/1-introduction.asc +++ b/book/01-introduction/1-introduction.asc @@ -1,7 +1,7 @@ [[_getting_started]] == Inicio - Sobre el Control de Versiones -Este capítulo habla de cómo comenzar a utilizar Git. Empezaremos describiendo algunos conceptos básicos sobre las herramientas de control de versiones; después, trataremos sobre cómo hacer que Git funcione en tu sistema; finalmente, exploraremos cómo configurarlo para empezar a trabajar con él. Al final de este capítulo deberás entender las razones por las cuales Git existe y conviene que lo uses, y deberás tener todo preparado para comenzar. +Este capítulo se va a hablar de cómo comenzar a utilizar Git. Empezaremos describiendo algunos conceptos básicos sobre las herramientas de control de versiones; después, trataremos de explicar cómo hacer que Git funcione en tu sistema; finalmente, exploraremos cómo configurarlo para empezar a trabajar con él. Al final de este capítulo deberás entender las razones por las cuales Git existe y conviene que lo uses, y deberás tener todo preparado para comenzar. include::sections/about-version-control.asc[] @@ -19,4 +19,4 @@ include::sections/help.asc[] === Resumen -Para este momento debes tener una comprensión básica de lo que es Git, y de cómo se diferencia de cualquier otro sistema de control de versiones centralizado que pudieras haber utilizado previamente. De igual manera, Git debe estar funcionando en tu sistema y configurado con tu identidad personal. Es hora de aprender los fundamentos de Git. +En este momento debes tener una comprensión básica de lo que es Git, y en que se diferencia de cualquier otro sistema de control de versiones centralizado que pudieras haber utilizado previamente. De igual manera, Git debe estar funcionando en tu sistema y configurado con tu identidad personal. Es hora de aprender los fundamentos de Git. From cfb74ccbfd6da8cdeb193a8fbace3a137c13dfe1 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Mon, 10 Jul 2017 12:12:33 +0200 Subject: [PATCH 02/11] Update 1-git-and-other-scms.asc --- .../09-git-and-other-scms/1-git-and-other-scms.asc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/09-git-and-other-scms/1-git-and-other-scms.asc b/book/09-git-and-other-scms/1-git-and-other-scms.asc index dcc354f6..b0da9194 100644 --- a/book/09-git-and-other-scms/1-git-and-other-scms.asc +++ b/book/09-git-and-other-scms/1-git-and-other-scms.asc @@ -1,12 +1,12 @@ -== Git and Other Systems +== Git y Otros Sistemas -The world isn't perfect. -Usually, you can't immediately switch every project you come in contact with to Git. -Sometimes you're stuck on a project using another VCS, and wish it was Git. -We'll spend the first part of this chapter learning about ways to use Git as a client when the project you're working on is hosted in a different system. +El mundo no es perfecto. +Por lo general, no se puede cambiar inmediatamente cada proyecto con el que está en contacto Git. +A veces estás atrapado en un proyecto usando otro VCS, y desearías poder usar Git. +Pasaremos la primera parte de este capítulo aprendiendo sobre cómo utilizar Git como cliente cuando el proyecto en el que se está trabajando está alojado en un sistema diferente. -At some point, you may want to convert your existing project to Git. -The second part of this chapter covers how to migrate your project into Git from several specific systems, as well as a method that will work if no pre-built import tool exists. +En algún momento, puede que desees convertir tu proyecto existente a Git. +La segunda parte de este capítulo describe cómo migrar tu proyecto en Git desde varios sistemas específicos, así como un método que funcionará si no existe una herramienta de importación pre-construida. === Git as a Client From e1c5b0f923b9b18d3041518cd38833fe981de278 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Mon, 10 Jul 2017 12:15:24 +0200 Subject: [PATCH 03/11] Update 1-git-and-other-scms.asc --- book/09-git-and-other-scms/1-git-and-other-scms.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/09-git-and-other-scms/1-git-and-other-scms.asc b/book/09-git-and-other-scms/1-git-and-other-scms.asc index b0da9194..8b963463 100644 --- a/book/09-git-and-other-scms/1-git-and-other-scms.asc +++ b/book/09-git-and-other-scms/1-git-and-other-scms.asc @@ -8,12 +8,12 @@ Pasaremos la primera parte de este capítulo aprendiendo sobre cómo utilizar Gi En algún momento, puede que desees convertir tu proyecto existente a Git. La segunda parte de este capítulo describe cómo migrar tu proyecto en Git desde varios sistemas específicos, así como un método que funcionará si no existe una herramienta de importación pre-construida. -=== Git as a Client +=== Git como Cliente -(((Git as a client))) -Git provides such a nice experience for developers that many people have figured out how to use it on their workstation, even if the rest of their team is using an entirely different VCS. -There are a number of these adapters, called ``bridges,'' available. -Here we'll cover the ones you're most likely to run into in the wild. +(((Git como Cliente))) +Git proporciona una experiencia tan agradable para los desarrolladores que muchas personas han descubierto cómo usarlo en su estación de trabajo, incluso si el resto de su equipo está usando un VCS completamente diferente. +Hay un número de estos adaptadores disponibles, llamados ``bridges''. +Aquí vamos a cubrir los que es más probable que se encuentren en la naturaleza. include::sections/client-svn.asc[] From 2a215804fde071c0f4a3de5bc9c1575cb7ff6924 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Mon, 10 Jul 2017 12:17:29 +0200 Subject: [PATCH 04/11] Update 1-git-and-other-scms.asc Spanish Translate complete. --- .../1-git-and-other-scms.asc | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/book/09-git-and-other-scms/1-git-and-other-scms.asc b/book/09-git-and-other-scms/1-git-and-other-scms.asc index 8b963463..0f2880ce 100644 --- a/book/09-git-and-other-scms/1-git-and-other-scms.asc +++ b/book/09-git-and-other-scms/1-git-and-other-scms.asc @@ -24,12 +24,12 @@ include::sections/client-p4.asc[] include::sections/client-tfs.asc[] [[_migrating]] -=== Migrating to Git +=== Migración a Git -(((Migrating to Git))) -If you have an existing codebase in another VCS but you've decided to start using Git, you must migrate your project one way or another. -This section goes over some importers for common systems, and then demonstrates how to develop your own custom importer. -You'll learn how to import data from several of the bigger professionally used SCM systems, because they make up the majority of users who are switching, and because high-quality tools for them are easy to come by. +(((Migración a Git))) +Si tiene una base de código existente en otro VCS pero ha decidido comenzar a usar Git, debe migrar su proyecto de una forma u otra. +Esta sección revisa algunos importadores para sistemas comunes y luego demuestra cómo desarrollar su propio importador personalizado. +Aprenderá a importar datos de varios de los sistemas SCM profesionales más grandes, ya que conforman la mayoría de los usuarios que están cambiando, y porque las herramientas de alta calidad para ellos son fáciles de conseguir. include::sections/import-svn.asc[] @@ -41,7 +41,6 @@ include::sections/import-tfs.asc[] include::sections/import-custom.asc[] -=== Summary - -You should feel comfortable using Git as a client for other version-control systems, or importing nearly any existing repository into Git without losing data. -In the next chapter, we'll cover the raw internals of Git so you can craft every single byte, if need be. +=== Resumen +Debería sentirse cómodo al usar Git como cliente para otros sistemas de control de versiones, o importar casi cualquier repositorio existente en Git sin perder datos. +En el próximo capítulo, cubriremos los elementos internos de Git para que pueda crear cada byte, si es necesario. From c0d1b582e9293a7ae86f3aac2bfbbd7a85260d6c Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Mon, 10 Jul 2017 12:57:13 +0200 Subject: [PATCH 05/11] Update distributed-workflows.asc --- .../sections/distributed-workflows.asc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index aed08666..62455677 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -21,15 +21,15 @@ El segundo desarrollador debe fusionar el trabajo del primero antes de subir sus Este concepto es válido tanto en Git como en Subversion This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git. -If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. -Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other. -Say John and Jessica both start working at the same time. -John finishes his change and pushes it to the server. -Then Jessica tries to push her changes, but the server rejects them. -She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges. -This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with. - -This is also not limited to small teams. With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously. +Si ya está cómodo con un flujo de trabajo centralizado en su empresa o en su equipo, puede seguir utilizando fácilmente ese flujo de trabajo con Git. +Simplemente configure un único repositorio, y dé a cada uno en su equipo acceso de empuje; Git no permitirá que los usuarios se sobrescriban entre sí. +Digamos que John y Jessica empiezan a trabajar al mismo tiempo. +John termina su cambio y lo empuja al servidor. +Entonces Jessica intenta empujar sus cambios, pero el servidor los rechaza. +Le dicen que está tratando de empujar cambios no rápidos y que no podrá hacerlo hasta que busque y se fusione. +Este flujo de trabajo es atractivo para mucha gente porque es un paradigma que muchos están familiarizados y cómodos. + +Esto tampoco se limita a los equipos pequeños. Con el modelo de ramificación de Git, es posible que cientos de desarrolladores trabajen con éxito en un único proyecto a través de docenas de ramas simultáneamente. [[_integration_manager]] ==== Integration-Manager Workflow From 80ecde5e5d3333ed50feba38746d0f78268f3151 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Wed, 12 Jul 2017 12:33:27 +0200 Subject: [PATCH 06/11] Update client-hg.asc Translate complete --- .../sections/client-hg.asc | 162 +++++++++--------- 1 file changed, 81 insertions(+), 81 deletions(-) diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index 984f3889..33b48921 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -1,19 +1,19 @@ -==== Git and Mercurial +==== Git y Mercurial (((Interoperation with other VCSs, Mercurial))) (((Mercurial))) -The DVCS universe is larger than just Git. -In fact, there are many other systems in this space, each with their own angle on how to do distributed version control correctly. -Apart from Git, the most popular is Mercurial, and the two are very similar in many respects. +El universo DVCS es más grande que el de Git. +De hecho, hay muchos otros sistemas en este espacio, cada uno con su propio ángulo sobre cómo hacer el control de versión distribuida correctamente. +Aparte de Git, el más popular es Mercurial, y los dos son muy similares en muchos aspectos. -The good news, if you prefer Git's client-side behavior but are working with a project whose source code is controlled with Mercurial, is that there's a way to use Git as a client for a Mercurial-hosted repository. -Since the way Git talks to server repositories is through remotes, it should come as no surprise that this bridge is implemented as a remote helper. -The project's name is git-remote-hg, and it can be found at https://github.com/felipec/git-remote-hg[]. +La buena noticia, si prefiere el comportamiento del cliente de Git pero que está trabajando con un proyecto cuyo código fuente está controlado con Mercurial, es que hay una manera de usar Git como cliente para un repositorio alojado en Mercurial. +Dado que la forma en que Git habla con los repositorios del servidor es a través de controles remotos, no debería sorprendernos que este puente se implemente como un ayudante remoto. +El nombre del proyecto es git-remote-hg, y se puede encontrar en https://github.com/felipec/git-remote-hg[]. ===== git-remote-hg -First, you need to install git-remote-hg. -This basically entails dropping its file somewhere in your path, like so: +Primero, necesitas instalar git-remote-hg. +Esto básicamente implica dejar caer su archivo en algún lugar de tu camino, así: [source,console] ---- @@ -22,35 +22,35 @@ $ curl -o ~/bin/git-remote-hg \ $ chmod +x ~/bin/git-remote-hg ---- -…assuming `~/bin` is in your `$PATH`. -Git-remote-hg has one other dependency: the `mercurial` library for Python. -If you have Python installed, this is as simple as: +... asumiendo que `~ / bin` está en su` $ PATH`. +Git-remote-hg tiene otra dependencia: la biblioteca `mercurial` para Python. +Si tienes instalado Python, es tan sencillo como: [source,console] ---- $ pip install mercurial ---- -(If you don't have Python installed, visit https://www.python.org/[] and get it first.) +(Si no tiene instalado Python, visite https://www.python.org/[] y consígalo primero.) -The last thing you'll need is the Mercurial client. -Go to http://mercurial.selenic.com/[] and install it if you haven't already. +Lo último que necesitarás es el cliente Mercurial. +Vaya a http://mercurial.selenic.com/[] e instálelo si aún no lo ha hecho. -Now you're ready to rock. -All you need is a Mercurial repository you can push to. -Fortunately, every Mercurial repository can act this way, so we'll just use the "hello world" repository everyone uses to learn Mercurial: +Ahora estás listo para el rock. +Todo lo que necesitas es un repositorio Mercurial al que puedes presionar. +Afortunadamente, todos los repositorios de Mercurial pueden actuar de esta manera, así que solo usaremos el repositorio de "hola mundo" que todos usan para aprender Mercurial: [source,console] ---- $ hg clone http://selenic.com/repo/hello /tmp/hello ---- -===== Getting Started +===== Empezando -Now that we have a suitable ``server-side'' repository, we can go through a typical workflow. -As you'll see, these two systems are similar enough that there isn't much friction. +Ahora que tenemos un repositorio ``server-side'' adecuado, podemos pasar por un flujo de trabajo típico. +Como verá, estos dos sistemas son lo suficientemente similares como para que no haya mucha fricción. -As always with Git, first we clone: +Como siempre con Git, primero clonamos: [source,console] ---- @@ -61,13 +61,13 @@ $ git log --oneline --graph --decorate * 65bb417 Create a standard "hello, world" program ---- -You'll notice that working with a Mercurial repository uses the standard `git clone` command. -That's because git-remote-hg is working at a fairly low level, using a similar mechanism to how Git's HTTP/S protocol is implemented (remote helpers). -Since Git and Mercurial are both designed for every client to have a full copy of the repository history, this command makes a full clone, including all the project's history, and does it fairly quickly. +Notará que el uso de un repositorio de Mercurial utiliza el comando `git clone` estándar. +Esto se debe a que git-remote-hg está funcionando a un nivel bastante bajo, utilizando un mecanismo similar a cómo se implementa el protocolo HTTP / S de Git (auxiliares remotos). +Dado que Git y Mercurial están diseñados para que cada cliente tenga una copia completa del historial del repositorio, este comando hace un clon completo, incluyendo todo el historial del proyecto, y lo hace con bastante rapidez. -The log command shows two commits, the latest of which is pointed to by a whole slew of refs. -It turns out some of these aren't actually there. -Let's take a look at what's actually in the `.git` directory: +El comando de registro muestra dos confirmaciones, la última de las cuales es señalada por un montón de refs. +Resulta que algunos de estos no están realmente allí. +Echemos un vistazo a lo que realmente está en el directorio `.git`: [source,console] ---- @@ -91,13 +91,13 @@ $ tree .git/refs 9 directories, 5 files ---- -Git-remote-hg is trying to make things more idiomatically Git-esque, but under the hood it's managing the conceptual mapping between two slightly different systems. -The `refs/hg` directory is where the actual remote refs are stored. -For example, the `refs/hg/origin/branches/default` is a Git ref file that contains the SHA-1 starting with ``ac7955c'', which is the commit that `master` points to. -So the `refs/hg` directory is kind of like a fake `refs/remotes/origin`, but it has the added distinction between bookmarks and branches. +Git-remote-hg está tratando de hacer las cosas más idiomáticamente Git-esque, pero bajo el capó es la gestión de la cartografía conceptual entre dos sistemas ligeramente diferentes. +El directorio `refs/hg` es donde se almacenan las referencias remotas reales. +Por ejemplo, el `refs/hg/origen/branches/default` es un archivo ref de Git que contiene el SHA-1 que comienza con ``ac7955c'', que es el commit que señala `master`. +Así que el directorio `refs/hg` es como un`refs/remotes/origen' falso, pero tiene la distinción añadida entre marcadores y ramas. -The `notes/hg` file is the starting point for how git-remote-hg maps Git commit hashes to Mercurial changeset IDs. -Let's explore a bit: +El archivo `notes/hg` es el punto de partida de cómo git-remote-hg asigna los hashes de commit de Git a los identificadores de cambios de Mercurial. +Vamos a explorar un poco: [source,console] ---- @@ -119,29 +119,29 @@ $ git cat-file -p ac9117f 0a04b987be5ae354b710cefeba0e2d9de7ad41a9 ---- -So `refs/notes/hg` points to a tree, which in the Git object database is a list of other objects with names. -`git ls-tree` outputs the mode, type, object hash, and filename for items inside a tree. -Once we dig down to one of the tree items, we find that inside it is a blob named ``ac9117f'' (the SHA-1 hash of the commit pointed to by `master`), with contents ``0a04b98'' (which is the ID of the Mercurial changeset at the tip of the `default` branch). +Así que `refs/notes/hg` apunta a un árbol, que en la base de datos de objetos Git es una lista de otros objetos con nombres. +`Git ls-tree` genera el modo, el tipo, el hash de objeto y el nombre de archivo de elementos dentro de un árbol. +Una vez que excavamos hacia abajo a uno de los elementos del árbol, encontramos que en su interior hay un blob llamado ``ac9117f'' (el hash SHA-1 del commit apuntado por `master`), con contenidos ``0a04b98'' Que es el identificador del conjunto de cambios Mercurial en la punta de la rama `default`). -The good news is that we mostly don't have to worry about all of this. -The typical workflow won't be very different from working with a Git remote. +La buena noticia es que en general no tenemos que preocuparnos por todo esto. +El flujo de trabajo típico no será muy diferente de trabajar con un control remoto de Git. -There's one more thing we should attend to before we continue: ignores. -Mercurial and Git use a very similar mechanism for this, but it's likely you don't want to actually commit a `.gitignore` file into a Mercurial repository. -Fortunately, Git has a way to ignore files that's local to an on-disk repository, and the Mercurial format is compatible with Git, so you just have to copy it over: +Hay una cosa más a la que debemos atender antes de continuar: ignora. +Mercurial y Git usan un mecanismo muy similar para esto, pero es probable que no quieras realmente comprometer un archivo `.gitignore` en un repositorio de Mercurial. +Afortunadamente, Git tiene una forma de ignorar los archivos que son locales a un repositorio en disco, y el formato Mercurial es compatible con Git, por lo que sólo tienes que copiarlo: [source,console] ---- $ cp .hgignore .git/info/exclude ---- -The `.git/info/exclude` file acts just like a `.gitignore`, but isn't included in commits. +El archivo `.git / info / exclude 'actúa como un` .gitignore`, pero no está incluido en commits. -===== Workflow +===== Flujo de Trabajo -Let's assume we've done some work and made some commits on the `master` branch, and you're ready to push it to the remote repository. -Here's what our repository looks like right now: +Supongamos que hemos hecho algunos trabajos e hicimos algunos commit en la rama `master` y estamos listos para enviarlo al repositorio remoto. +A continuación, le mostramos nuestro repositorio: [source,console] ---- @@ -152,8 +152,8 @@ $ git log --oneline --graph --decorate * 65bb417 Create a standard "hello, world" program ---- -Our `master` branch is two commits ahead of `origin/master`, but those two commits exist only on our local machine. -Let's see if anyone else has been doing important work at the same time: +Nuestra rama `master` está a dos compromisos por delante de `origin/master`, pero estos dos commits sólo existen en nuestra máquina local. +Veamos si alguien más ha estado haciendo un trabajo importante al mismo tiempo: [source,console] ---- @@ -172,9 +172,9 @@ $ git log --oneline --graph --decorate --all * 65bb417 Create a standard "hello, world" program ---- -Since we used the `--all` flag, we see the ``notes'' refs that are used internally by git-remote-hg, but we can ignore them. -The rest is what we expected; `origin/master` has advanced by one commit, and our history has now diverged. -Unlike the other systems we work with in this chapter, Mercurial is capable of handling merges, so we're not going to do anything fancy. +Puesto que utilizamos el indicador `--all`, vemos las` `notes '' refs que son utilizadas internamente por git-remote-hg, pero podemos ignorarlas. +El resto es lo que esperábamos; `Origen / master` ha avanzado por una comisión, y nuestra historia ha divergido ahora. +A diferencia de los otros sistemas con los que trabajamos en este capítulo, Mercurial es capaz de manejar fusiones, por lo que no vamos a hacer nada extravagante. [source,console] ---- @@ -194,8 +194,8 @@ $ git log --oneline --graph --decorate * 65bb417 Create a standard "hello, world" program ---- -Perfect. -We run the tests and everything passes, so we're ready to share our work with the rest of the team: +Perfecto. +Hacemos las pruebas y todo pasa, así que estamos listos para compartir nuestro trabajo con el resto del equipo: [source,console] ---- @@ -204,8 +204,8 @@ To hg::/tmp/hello df85e87..0c64627 master -> master ---- -That's it! -If you take a look at the Mercurial repository, you'll see that this did what we'd expect: +¡Eso es! +Si echa un vistazo al repositorio de Mercurial, verá que esto hizo lo que esperábamos: [source,console] ---- @@ -229,16 +229,16 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm Create a standard "hello, world" program ---- -The changeset numbered _2_ was made by Mercurial, and the changesets numbered _3_ and _4_ were made by git-remote-hg, by pushing commits made with Git. +El conjunto de cambios numerado _2_ fue hecho por Mercurial, y los conjuntos de cambios numerados _3_ y _4_ fueron hechos por git-remote-hg, al empujar los commit hechos con Git. -===== Branches and Bookmarks +===== Branches(Ramas) y Bookmarks(Marcadores) -Git has only one kind of branch: a reference that moves when commits are made. -In Mercurial, this kind of a reference is called a ``bookmark,'' and it behaves in much the same way as a Git branch. +Git tiene sólo un tipo de rama: una referencia que se mueve cuando se hacen los compromisos. +En Mercurial, este tipo de referencia se llama marcador, y se comporta de la misma manera que una rama de Git. -Mercurial's concept of a ``branch'' is more heavyweight. -The branch that a changeset is made on is recorded _with the changeset_, which means it will always be in the repository history. -Here's an example of a commit that was made on the `develop` branch: +El concepto de Mercurial de una "rama" es más pesado. +La rama en la que se realiza un conjunto de cambios se registra con el conjunto de cambios, lo que significa que siempre estará en el historial del repositorio. +He aquí un ejemplo de un commit que se hizo en la rama `develop`: [source,console] ---- @@ -251,11 +251,11 @@ date: Thu Aug 14 20:06:38 2014 -0700 summary: More documentation ---- -Note the line that begins with ``branch''. -Git can't really replicate this (and doesn't need to; both types of branch can be represented as a Git ref), but git-remote-hg needs to understand the difference, because Mercurial cares. +Observe la línea que comienza con ``Branch''. +Git no puede realmente replicar esto (y no necesita, ambos tipos de rama puede representarse como una referencia Git), pero git-remote-hg necesita entender la diferencia, porque Mercurial se preocupa. -Creating Mercurial bookmarks is as easy as creating Git branches. -On the Git side: +Crear marcadores de Mercurial es tan fácil como crear ramas de Git. +En el lado Git: [source,console] ---- @@ -266,8 +266,8 @@ To hg::/tmp/hello * [new branch] featureA -> featureA ---- -That's all there is to it. -On the Mercurial side, it looks like this: +Eso es todo al respecto. +En el lado mercurial, se ve así: [source,console] ---- @@ -296,10 +296,10 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm Create a standard "hello, world" program ---- -Note the new `[featureA]` tag on revision 5. -These act exactly like Git branches on the Git side, with one exception: you can't delete a bookmark from the Git side (this is a limitation of remote helpers). +Tenga en cuenta la nueva etiqueta `[featureA]` en la revisión 5. +Éstos actúan exactamente como las ramas de Git en el lado de Git, con una excepción: usted no puede suprimir un marcador del lado de Git (ésta es una limitación de ayudantes remotos). -You can work on a ``heavyweight'' Mercurial branch also: just put a branch in the `branches` namespace: +Puedes trabajar con una rama ``heavyweight'' de Mercurial si: introduces ramas en los espacios para `branches` así: [source,console] ---- @@ -312,7 +312,7 @@ To hg::/tmp/hello * [new branch] branches/permanent -> branches/permanent ---- -Here's what that looks like on the Mercurial side: +Esto es lo que aparece en el lado de Mercurial: [source,console] ---- @@ -345,11 +345,11 @@ o changeset: 5:bd5ac26f11f9 [...] ---- -The branch name ``permanent'' was recorded with the changeset marked _7_. +El nombre de la rama ``permanent'' se registró en el conjunto de cambios marcados con _7_. -From the Git side, working with either of these branch styles is the same: just checkout, commit, fetch, merge, pull, and push as you normally would. -One thing you should know is that Mercurial doesn't support rewriting history, only adding to it. -Here's what our Mercurial repository looks like after an interactive rebase and a force-push: +Desde el lado de Git, el trabajo con cualquiera de estos estilos de rama es el mismo: sólo checkout, commit, fetch, merge, pull y push como lo haría normalmente. +Una cosa que usted debe saber es que Mercurial no apoya la historia de la reescritura, agregando solamente a ella. +Esto es lo que nuestro repositorio de Mercurial parece después de un rebase interactivo y un force-push: [source,console] ---- @@ -388,11 +388,11 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm Create a standard "hello, world" program ---- -Changesets _8_, _9_, and _10_ have been created and belong to the `permanent` branch, but the old changesets are still there. -This can be *very* confusing for your teammates who are using Mercurial, so try to avoid it. +CHangesets _8_, _9_ y _10_ han sido creados y pertenecen a la rama `permanent`, pero los viejos changesets siguen ahí. +Esto puede ser *muy* confuso para sus compañeros de equipo que están usando Mercurial, así que trate de evitarlo. -===== Mercurial Summary +===== Resumen de Mercurial -Git and Mercurial are similar enough that working across the boundary is fairly painless. -If you avoid changing history that's left your machine (as is generally recommended), you may not even be aware that the other end is Mercurial. +Git y Mercurial son bastante similares que trabajar a través de la frontera es bastante indoloro. +Si evita cambiar el historial que ha dejado su máquina (como se recomienda generalmente), puede que ni siquiera sepa que el otro extremo es Mercurial. From 62f5d57f1e72a7719588b538667d3a9147c8add6 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Wed, 12 Jul 2017 12:45:57 +0200 Subject: [PATCH 07/11] Update import-tfs.asc Section translate complete --- .../sections/import-tfs.asc | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc index 77e6d943..61eda335 100644 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -2,13 +2,13 @@ ==== TFS (((TFS)))(((Importing, from TFS))) -If your team is converting their source control from TFVC to Git, you'll want the highest-fidelity conversion you can get. -This means that, while we covered both git-tfs and git-tf for the interop section, we'll only be covering git-tfs for this part, because git-tfs supports branches, and this is prohibitively difficult using git-tf. +Si su equipo está convirtiendo su control de código fuente de TFVC a Git, querrá la conversión de mayor fidelidad que pueda obtener. +Esto significa que mientras cubrimos git-tfs y git-tf para la sección de interoperabilidad, sólo cubriremos git-tfs para esta parte, porque git-tfs soporta ramificaciones, y esto es prohibitivamente difícil usando git-tf. [NOTE] ==== -This is a one-way conversion. -The resulting Git repository won't be able to connect with the original TFVC project. +Se trata de una conversión unidireccional. +El repositorio Git resultante no podrá conectarse con el proyecto TFVC original. ==== The first thing to do is map usernames. @@ -20,41 +20,41 @@ You can get this information from the `tf` command-line client, like so: PS> tf history $/myproject -recursive > AUTHORS_TMP ---- -This grabs all of the changesets in the history of the project and put it in the AUTHORS_TMP file that we will process to extract the data of the 'User' column (the 2nd one). -Open the file and find at which characters start and end the column and replace, in the following command-line, the parameters `11-20` of the `cut` command with the ones found: +Esto agarra todos los conjuntos de cambios de la historia del proyecto y lo coloca en el archivo AUTHORS_TMP que procesaremos para extraer los datos de la columna 'Usuario' (el segundo). +Abre el archivo y busca en qué caracteres comienzan y terminan la columna y reemplazan, en la línea de comandos siguiente, los parámetros `11-20` del comando` cut` con los que se encuentran: [source,powershell] ---- PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | uniq | sort > AUTHORS ---- -The `cut` command keeps only the characters between 11 and 20 from each line. -The `tail` command skips the first two lines, which are field headers and ASCII-art underlines. -The result of all of this is piped to `uniq` to eliminate duplicates, and saved to a file named `AUTHORS`. -The next step is manual; in order for git-tfs to make effective use of this file, each line must be in this format: +El comando `cut` mantiene sólo los caracteres entre 11 y 20 de cada línea. +El comando `tail` omite las dos primeras líneas, que son cabeceras de campo y subrayados ASCII-art. +El resultado de todo esto se canaliza a `uniq` para eliminar duplicados y se guarda en un archivo llamado` AUTHORS`. +El siguiente paso es manual; Para que git-tfs haga un uso efectivo de este archivo, cada línea debe estar en este formato: [source,text] ---- DOMAIN\username = User Name ---- -The portion on the left is the ``User'' field from TFVC, and the portion on the right side of the equals sign is the user name that will be used for Git commits. +La parte de la izquierda es el campo ``Usuario'' de TFVC, y la porción en el lado derecho del signo de iguales es el nombre de usuario que se utilizará para los compromisos de Git. -Once you have this file, the next thing to do is make a full clone of the TFVC project you're interested in: +Una vez que tengas este archivo, lo siguiente que debes hacer es hacer un clon completo del proyecto TFVC en el que estás interesado: [source,powershell] ---- PS> git tfs clone --with-branches --authors=AUTHORS https://username.visualstudio.com/DefaultCollection $/project/Trunk project_git ---- -Next you'll want to clean the `git-tfs-id` sections from the bottom of the commit messages. -The following command will do that: +A continuación, deseará limpiar las secciones `git-tfs-id` desde la parte inferior de los mensajes de confirmación. +El siguiente comando hará lo siguiente: [source,powershell] ---- PS> git filter-branch -f --msg-filter 'sed "s/^git-tfs-id:.*$//g"' -- --all ---- -That uses the `sed` command from the Git-bash environment to replace any line starting with ``git-tfs-id:'' with emptiness, which Git will then ignore. +Que utiliza el comando `sed` desde el entorno Git-bash para reemplazar cualquier línea que empiece por ``git-tfs-id:'' con vacío, que Git luego ignorará. -Once that's all done, you're ready to add a new remote, push all your branches up, and have your team start working from Git. +Una vez que todo está hecho, estás listo para añadir un nuevo mando a distancia, empujar todas sus ramas hacia arriba, y hacer que su equipo comience a trabajar desde Git. From 020b8cb9a153779cc788968941b0b99a48c645c5 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Wed, 12 Jul 2017 12:53:36 +0200 Subject: [PATCH 08/11] Update 1-git-tools.asc Section Complete --- book/07-git-tools/1-git-tools.asc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/07-git-tools/1-git-tools.asc b/book/07-git-tools/1-git-tools.asc index 073eae5f..1fd9ffe4 100644 --- a/book/07-git-tools/1-git-tools.asc +++ b/book/07-git-tools/1-git-tools.asc @@ -1,10 +1,10 @@ [[_git_tools]] -== Git Tools +== Herramientas de Git -By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. -You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. +Por ahora, ha aprendido la mayoría de los comandos y flujos de trabajo del día a día que necesita para administrar o mantener un repositorio de Git para su control de código fuente. +Has logrado las tareas básicas de rastrear y comprometer archivos y has aprovechado el poder de la zona de puesta en escena y el tema ligero de ramificación y fusión. -Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point. +Ahora explorará una serie de cosas muy poderosas que Git puede hacer que no necesariamente puede utilizar en el día a día, pero que puede que necesite en algún momento. include::sections/revision-selection.asc[] @@ -34,9 +34,9 @@ include::sections/replace.asc[] include::sections/credentials.asc[] -=== Summary +=== Resumen -You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. -When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. -If you want to use subprojects in your project, you’ve learned how to accommodate those needs. -At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so. +Ha visto una serie de herramientas avanzadas que le permiten manipular sus compromisos y el área de puesta en escena con mayor precisión. +Cuando note problemas, debería ser capaz de averiguar fácilmente qué commit los introdujo, cuándo y por quién. +Si desea utilizar subproyectos en su proyecto, ha aprendido a adaptarse a esas necesidades. +En este punto, usted debe ser capaz de hacer la mayoría de las cosas en Git que usted necesita en la línea de comandos día a día y se sienten cómodos haciéndolo. From 80db9a585ba7ae10b7fc03d98d22a51852937f79 Mon Sep 17 00:00:00 2001 From: Xxdaniels751xX Date: Wed, 12 Jul 2017 13:21:02 +0200 Subject: [PATCH 09/11] Update replace.asc Section translate complete --- book/07-git-tools/sections/replace.asc | 48 +++++++++++++------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 3d1e1a21..19956da6 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -1,15 +1,15 @@ [[_replace]] === Replace -Git's objects are unchangeable, but it does provide an interesting way to pretend to replace objects in it's database with other objects. +Los objetos de Git son inmutables, pero proporciona una manera interesante de pretender reemplazar objetos en su base de datos con otros objetos. -The `replace` command lets you specify an object in Git and say "every time you see this, pretend it's this other thing". This is most commonly useful for replacing one commit in your history with another one. +El comando `replace` le permite especificar un objeto en Git y decir" cada vez que vea esto, fingir que es esta otra cosa ". Esto es más útil para reemplazar un commit en tu historia con otro. -For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining. You can graft one history onto the other by `replace`ing the earliest commit in the new line with the latest commit on the older one. This is nice because it means that you don't actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHA-1s). +Por ejemplo, supongamos que tiene un gran historial de códigos y desea dividir su repositorio en un breve historial para nuevos desarrolladores y una historia mucho más larga para las personas interesadas en la minería de datos. Puede injertar una historia en la otra mediante `replace`ing el commit más antiguo en la nueva línea con el último commit en el anterior. Esto es bueno porque significa que en realidad no tienes que reescribir cada commit en la nueva historia, como normalmente tendrías que hacer para unirlos juntos (porque el parentesco efectúa los SHA-1s). -Let's try this out. Let's take an existing repository, split it into two repositories, one recent and one historical, and then we'll see how we can recombine them without modifying the recent repositories SHA-1 values via `replace`. +Vamos a probar esto. Tomemos un repositorio existente, lo dividimos en dos repositorios, uno reciente y otro histórico, y luego veremos cómo podemos recombinarlos sin modificar los repositorios recientes SHA-1 a través de `replace`. -We'll use a simple repository with five simple commits: +Usaremos un repositorio sencillo con cinco compromisos simples: [source,console] ---- @@ -21,11 +21,11 @@ c6e1e95 fourth commit c1822cf first commit ---- -We want to break this up into two lines of history. One line goes from commit one to commit four - that will be the historical one. The second line will just be commits four and five - that will be the recent history. +zQueremos dividir esto en dos líneas de la historia. Una línea pasa de comprometer uno a cometer cuatro - que será el histórico. La segunda línea sólo se compromete cuatro y cinco - que será la historia reciente. image::images/replace1.png[] -Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the master branch of a new remote repository. +Bueno, la creación de la historia histórica es fácil, sólo podemos poner una rama en la historia y luego empujar esa rama a la rama principal de un nuevo repositorio remoto. [source,console] ---- @@ -40,7 +40,7 @@ c1822cf first commit image::images/replace2.png[] -Now we can push the new `history` branch to the `master` branch of our new repository: +Ahora podemos hacer push a la nueva rama `history` a la rama` master` de nuestro nuevo repositorio: [source,console] ---- @@ -56,7 +56,7 @@ To git@github.com:schacon/project-history.git * [new branch] history -> master ---- -OK, so our history is published. Now the harder part is truncating our recent history down so it's smaller. We need an overlap so we can replace a commit in one with an equivalent commit in the other, so we're going to truncate this to just commits four and five (so commit four overlaps). +OK, así que nuestra historia se publica. Ahora la parte más difícil es truncar nuestra historia reciente por lo que es más pequeño. Necesitamos una superposición para que podamos reemplazar un commit en uno con un commit equivalente en el otro, por lo que vamos a truncar esto a sólo comete cuatro y cinco (así cometer cuatro superposiciones). [source,console] ---- @@ -68,9 +68,9 @@ c6e1e95 (history) fourth commit c1822cf first commit ---- -It's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it. +En este caso, es útil crear un commit de base que tenga instrucciones sobre cómo expandir el historial, por lo que otros desarrolladores saben qué hacer si acceden al primer commit en el historial truncado y necesitan más. Por lo tanto, lo que vamos a hacer es crear un objeto de confirmación inicial como nuestro punto base con instrucciones, luego rebase los compromisos restantes (cuatro y cinco) encima de él. -To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. So, our base commit will be based off of that tree. We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA-1 back. +Para ello, debemos elegir un punto para dividir en, que para nosotros es el tercer commit, que es `9c68fdc` en SHA-speak. Por lo tanto, nuestra comisión base se basará en ese árbol. Podemos crear nuestro commit base con el comando `commit-tree`, que solo toma un árbol y nos dará un nuevo objeto de commit sin padres SHA-1. [source,console] ---- @@ -80,12 +80,12 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree} [NOTE] ===== -The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands. These are commands that are not generally meant to be used directly, but instead are used by **other** Git commands to do smaller jobs. On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use. You can read more about plumbing commands in <<_plumbing_porcelain>> +El comando `commit-tree` es uno de un conjunto de comandos que comúnmente se denominan comandos 'plumbing'. Estos son comandos que no suelen ser utilizados directamente, sino que son utilizados por ** ** ** otros comandos Git para hacer trabajos más pequeños. En ocasiones, cuando estamos haciendo cosas más extrañas como estas, nos permiten hacer cosas de nivel muy bajo, pero no son para uso diario. Puede leer más acerca de los comandos de plomería en << _ plumbing_porcelain >> ===== image::images/replace3.png[] -OK, so now that we have a base commit, we can rebase the rest of our history on top of that with `git rebase --onto`. The `--onto` argument will be the SHA-1 we just got back from `commit-tree` and the rebase point will be the third commit (the parent of the first commit we want to keep, `9c68fdc`): +OK, así que ahora que tenemos un commit de base, podemos rebase el resto de nuestra historia encima de eso con 'rebase de git --onto`. El argumento `--onto` será el SHA-1 que acabamos de regresar de` commit-tree` y el punto de rebase será el tercer commit (el padre del primer commit que queremos mantener, `9c68fdc`): [source,console] ---- @@ -97,10 +97,10 @@ Applying: fifth commit image::images/replace4.png[] -OK, so now we've re-written our recent history on top of a throw away base commit that now has instructions in it on how to reconstitute the entire history if we wanted to. We can push that new history to a new project and now when people clone that repository, they will only see the most recent two commits and then a base commit with instructions. +Así que ahora hemos re-escrito nuestra historia reciente en la parte superior de un tiro de base de comisión que ahora tiene instrucciones sobre cómo reconstruir toda la historia si queríamos. Podemos empujar esa nueva historia a un nuevo proyecto y ahora, cuando las personas clonen ese repositorio, solo verán los dos compromisos más recientes y luego un commit de base con instrucciones. -Let's now switch roles to someone cloning the project for the first time who wants the entire history. -To get the history data after cloning this truncated repository, one would have to add a second remote for the historical repository and fetch: +Cambiemos de roles a alguien que clonara el proyecto por primera vez y que quiere toda la historia. +Para obtener los datos del historial después de clonar este repositorio truncado, habría que añadir un segundo mando a distancia para el repositorio histórico y buscar: [source,console] ---- @@ -118,7 +118,7 @@ From https://github.com/schacon/project-history * [new branch] master -> project-history/master ---- -Now the collaborator would have their recent commits in the `master` branch and the historical commits in the `project-history/master` branch. +Ahora el colaborador tendría sus compromisos recientes en la rama `master` y los compromisos históricos en la rama `project-history/master`. [source,console] ---- @@ -134,14 +134,14 @@ c6e1e95 fourth commit c1822cf first commit ---- -To combine them, you can simply call `git replace` with the commit you want to replace and then the commit you want to replace it with. So we want to replace the "fourth" commit in the master branch with the "fourth" commit in the `project-history/master` branch: +Para combinarlos, simplemente puede llamar a `git replace` con el commit que desea reemplazar y luego el commit con el que desea reemplazarlo. Así que queremos reemplazar el "cuarto" commit en la rama maestra con el "cuarto" commit en la rama `project-history/master`: [source,console] ---- $ git replace 81a708d c6e1e95 ---- -Now, if you look at the history of the `master` branch, it appears to look like this: +Ahora bien, si nos fijamos en la historia de la rama `master`, parece que se ve así: [source,console] ---- @@ -153,11 +153,11 @@ e146b5f fifth commit c1822cf first commit ---- -Cool, right? Without having to change all the SHA-1s upstream, we were able to replace one commit in our history with an entirely different commit and all the normal tools (`bisect`, `blame`, etc) will work how we would expect them to. +Genial, ¿verdad? Sin tener que cambiar todos los SHA-1s upstream, pudimos reemplazar un commit en nuestra historia con un commit totalmente diferente y todas las herramientas normales (`bisect`,` blame`, etc.) funcionarán como esperamos . image::images/replace5.png[] -Interestingly, it still shows `81a708d` as the SHA-1, even though it's actually using the `c6e1e95` commit data that we replaced it with. Even if you run a command like `cat-file`, it will show you the replaced data: +Curiosamente, todavía muestra `81a708d` como el SHA-1, a pesar de que en realidad está utilizando los datos de confirmación` c6e1e95` con los que lo reemplazamos. Incluso si ejecuta un comando como `cat-file`, le mostrará los datos reemplazados: [source,console] ---- @@ -170,9 +170,9 @@ committer Scott Chacon 1268712581 -0700 fourth commit ---- -Remember that the actual parent of `81a708d` was our placeholder commit (`622e88e`), not `9c68fdce` as it states here. +Recuerde que el padre real de `81a708d` fue nuestro placeholder commit (`622e88e`), no `9c68fdce`, como se indica aquí. -Another interesting thing is that this data is kept in our references: +Otra cosa interesante es que estos datos se guardan en nuestras referencias: [source,console] ---- @@ -184,4 +184,4 @@ e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit refs/remotes/origin/master c6e1e95051d41771a649f3145423f8809d1a74d4 commit refs/replace/81a708dd0e167a3f691541c7a6463343bc457040 ---- -This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it. This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why separate them?) but it can be useful in other circumstances. +Esto significa que es fácil compartir nuestro reemplazo con otros, porque podemos empujar esto a nuestro servidor y otras personas pueden descargarlo fácilmente. Esto no es tan útil en el escenario de injerto de historia que hemos pasado aquí (ya que todo el mundo estaría descargando ambas historias de todos modos, ¿por qué separarlas?), Pero puede ser útil en otras circunstancias. From 0bd4cdac0829adb4121f50c60cff438d1d2b21a8 Mon Sep 17 00:00:00 2001 From: Andres Mancera Date: Fri, 11 Aug 2017 09:42:40 -0700 Subject: [PATCH 10/11] contributors.asc updated after pull requests #55, #57 and #59 --- book/contributors.asc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/book/contributors.asc b/book/contributors.asc index ec9c6dcc..137fd1f8 100644 --- a/book/contributors.asc +++ b/book/contributors.asc @@ -5,11 +5,13 @@ Debido a que este es un libro cuya traducción es "Open Source", hemos recibido [source] ---- -71 Andrés Mancera +72 Andrés Mancera 63 José Antonio Muñoz Jiménez 36 Juan Jose Amor Iglesias 31 blasillo 15 Carlos A. Henríquez Q. + 9 Xxdaniels751xX + 7 Pilar Arr 4 German Gonzalez-Morris 4 Moises Ariel Hernández Rojo 4 Dmunoz94 @@ -17,6 +19,7 @@ Debido a que este es un libro cuya traducción es "Open Source", hemos recibido 2 Yoandy 2 José Carlos García 2 Mario R. Rincón-Díaz + 1 Christopher Díaz 1 Vladimir Rodríguez 1 fatfer 1 Eliecer Daza From d63ce7224baf5ab945671fde47527af0d6e1c107 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christopher=20D=C3=ADaz?= Date: Fri, 11 Aug 2017 12:46:59 -0500 Subject: [PATCH 11/11] =?UTF-8?q?Traducci=C3=B3n=2007-git-tools/.../signin?= =?UTF-8?q?g.asc=20y=20status?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/07-git-tools/sections/signing.asc | 52 ++++++++++++-------------- status.json | 2 +- 2 files changed, 25 insertions(+), 29 deletions(-) diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index 47a8ade4..17d78511 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -1,11 +1,11 @@ [[_signing]] -=== Signing Your Work +=== Firmando tu trabajo -Git is cryptographically secure, but it's not foolproof. If you're taking work from others on the internet and want to verify that commits are actually from a trusted source, Git has a few ways to sign and verify work using GPG. +Git es criptográficamente seguro, pero no es a prueba de tontos. Si estás tomando trabajo de otros de internet y quieres verificar que los commits son realmente de fuentes seguras, Git tiene unas cuantas maneras de firmar y verificar utilizando GPG. -==== GPG Introduction +==== Introducción a GPG -First of all, if you want to sign anything you need to get GPG configured and your personal key installed. +Antes que nada, si quieres firmar cualquier cosa necesitas tener configurado GPG y tu llave personal instalada. [source,console] ---- @@ -17,26 +17,25 @@ uid Scott Chacon (Git signing key) sub 2048R/874529A9 2014-06-04 ---- -If you don't have a key installed, you can generate one with `gpg --gen-key`. +Si no tienes una llave instalada, puedes generar una con `gpg --gen-key`. [source,console] ---- gpg --gen-key ---- -Once you have a private key to sign with, you can configure Git to use it for signing things by setting the `user.signingkey` config setting. +Una vez que tengas una llave privada para firmar, puedes configurar Git para usarla y firmar cosas configurando la opción `user.signingkey`. [source,console] ---- git config --global user.signingkey 0A46826A ---- -Now Git will use your key by default to sign tags and commits if you want. +Ahora Git usará tu llave por defecto para firmar tags y commits si tu quieres. -==== Signing Tags +==== Firmando Tags -If you have a GPG private key setup, you can now use it to sign new tags. -All you have to do is use `-s` instead of `-a`: +Si tienes una llave GPG privada configurada, ahora puedes usarla para firmar tags. Todo lo que tienes que hacer es usar `-s` en lugar de `-a`: [source,console] ---- @@ -47,7 +46,7 @@ user: "Ben Straub " 2048-bit RSA key, ID 800430EB, created 2014-05-04 ---- -If you run `git show` on that tag, you can see your GPG signature attached to it: +Si ejecutas `git show` en ese tag, puedes ver tu firma GPG adjunta a él: [source,console] -------- @@ -76,11 +75,9 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number -------- -==== Verifying Tags +==== Verficando Tags -To verify a signed tag, you use `git tag -v [tag-name]`. -This command uses GPG to verify the signature. -You need the signer’s public key in your keyring for this to work properly: +Para verificar un tag firmado, usa `git tag -v [nombre-de-tag]`. Este comando usa GPG para verificar la firma. Necesitas tener guardada la llave pública del usuario para que esto funcione de manera apropiada: [source,console] ---- @@ -99,7 +96,7 @@ gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A ---- -If you don’t have the signer’s public key, you get something like this instead: +Si no tienes la llave pública de quien firmó, obtendrás algo como esto en cambio: [source,console] ---- @@ -109,10 +106,9 @@ error: could not verify the tag 'v1.4.2.1' ---- [[_signing_commits]] -==== Signing Commits +==== Firmando Commits -In more recent versions of Git (v1.7.9 and above), you can now also sign individual commits. -If you're interested in signing commits directly instead of just the tags, all you need to do is add a `-S` to your `git commit` command. +En versiones más recientes de Git (v1.7.9 en adelante), ahora puedes firmar commits individuales. Si estás interesado en firmar commits directamente en lugar de solo los tags, todo lo que necesitas hacer es agregar un `-S` a tu comando `git commit`. [source,console] ---- @@ -128,7 +124,7 @@ user: "Scott Chacon (Git signing key) " create mode 100644 lib/git.rb ---- -To see and verify these signatures, there is also a `--show-signature` option to `git log`. +Para ver y verificar las firmas, también existe una opción `--show-signature` para `git log`. [source,console] ---- @@ -142,7 +138,7 @@ Date: Wed Jun 4 19:49:17 2014 -0700 signed commit ---- -Additionally, you can configure `git log` to check any signatures it finds and list them in it's output with the `%G?` format. +Adicionalmente, puedes configurar `git log` para verificar cualquier firma que encuentre y listarlas en su salida con el formato `%G?`. [source,console] ---- @@ -154,11 +150,11 @@ ca82a6d N Scott Chacon changed the version number a11bef0 N Scott Chacon first commit ---- -Here we can see that only the latest commit is signed and valid and the previous commits are not. +Aquí podemos ver que solo el último commit es firmado y válido y los commits previos no. -In Git 1.8.3 and later, "git merge" and "git pull" can be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the `--verify-signatures` command. +En Git 1.8.3 y posteriores, "git merge" y "git pull" pueden ser configurados para inspeccionar y rechazar cualquier commit que no adjunte una firma GPG de confianza con el comando `--verify-signatures`. -If you use this option when merging a branch and it contains commits that are not signed and valid, the merge will not work. +Si se usa esta opción cuando se fusiona una rama y esta contiene commits que no están firmados y son válidos, la fusión no funcionará. [source,console] ---- @@ -166,7 +162,7 @@ $ git merge --verify-signatures non-verify fatal: Commit ab06180 does not have a GPG signature. ---- -If the merge contains only valid signed commits, the merge command will show you all the signatures it has checked and then move forward with the merge. +Si una fusión contiene solo commits válidos y firmados, el comando merge mostrará todas las firmas que ha revisado y después procederá con la fusión. [source,console] ---- @@ -178,7 +174,7 @@ Fast-forward 1 file changed, 2 insertions(+) ---- -You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and furthermore signs the resulting merge commit. +También se puede utilizar la opción `-S` junto con el mismo comando `git merge` para firmar el commit resultante. El siguiente ejemplo verifica que cada commit en la rama por ser fusionada esté firmado y también firma el commit resultado de la fusión. [source,console] ---- @@ -194,6 +190,6 @@ Merge made by the 'recursive' strategy. 1 file changed, 2 insertions(+) ---- -==== Everyone Must Sign +==== Todos deben firmar -Signing tags and commits is great, but if you decide to use this in your normal workflow, you'll have to make sure that everyone on your team understands how to do so. If you don't, you'll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow. +Firmar tags y commits es grandioso, pero si decides usar esto en tu flujo de trabajo normal, tendrás que asegurar que todos en el equipo entiendan cómo hacerlo. Si no, terminarás gastando mucho tiempo ayudando a las personas a descubrir cómo reescribir sus commits con versiones firmadas. Asegúrate de entender GPG y los beneficios de firmar cosas antes de adoptarlo como parte de tu flujo de trabajo normal. diff --git a/status.json b/status.json index 69572fb4..3985c958 100644 --- a/status.json +++ b/status.json @@ -71,7 +71,7 @@ "sections/revision-selection.asc": 0, "sections/rewriting-history.asc": 0, "sections/searching.asc": 0, - "sections/signing.asc": 0, + "sections/signing.asc": 100, "sections/stashing-cleaning.asc": 0, "sections/submodules.asc": 0, "sections/subtree-merges.asc": 0