Partial Update contributing.asc

book/05-distributed-git/sections/contributing.asc

@@ -1,102 +1,102 @@
 [[_contributing_project]]
-=== Contributing to a Project
+=== Contribuyendo a un Proyecto
 
 (((contributing)))
-The main difficulty with describing how to contribute to a project is that there are a huge number of variations on how it's done.
-Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute – every project is a bit different.
-Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method.
-
-The first variable is active contributor count – how many users are actively contributing code to this project, and how often?
-In many instances, you'll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects.
-For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day.
-This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged.
-Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied.
-How can you keep your code consistently up to date and your commits valid?
-
-The next variable is the workflow in use for the project.
-Is it centralized, with each developer having equal write access to the main codeline?
-Does the project have a maintainer or integration manager who checks all the patches?
-Are all the patches peer-reviewed and approved?
-Are you involved in that process?
-Is a lieutenant system in place, and do you have to submit your work to them first?
-
-The next issue is your commit access.
-The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't.
-If you don't have write access, how does the project prefer to accept contributed work?
-Does it even have a policy?
-How much work are you contributing at a time?
-How often do you contribute?
-
-All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you.
-We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples.
+La principal dificultad con la descripción de cómo contribuir a un proyecto es que hay una gran cantidad de variaciones sobre cómo se hace.
+Debido a que Git es muy flexible, las personas pueden y trabajan juntas de muchas maneras, y es problemático describir cómo debe contribuir: cada proyecto es un poco diferente.
+Algunas de las variables involucradas son conteo de contribuyentes activos, flujo de trabajo elegido, acceso de confirmación y posiblemente el método de contribución externa.
+
+La primera variable es el conteo de contribuyentes activos: ¿cuántos usuarios están contribuyendo activamente al código de este proyecto y con qué frecuencia?
+En muchos casos, tendrá dos o tres desarrolladores con algunos commits por día, o posiblemente menos para proyectos un tanto inactivos.
+Para empresas o proyectos más grandes, la cantidad de desarrolladores podría ser de miles, con cientos o miles de compromisos cada día.
+Esto es importante porque con más y más desarrolladores, se encontrará con más problemas para asegurarse de que su código se aplique de forma limpia o se pueda fusionar fácilmente.
+Los cambios que envíe pueden quedar obsoletos o severamente interrumpidos por el trabajo que se fusionó mientras estaba trabajando o mientras los cambios estaban esperando ser aprobados o aplicados.
+¿Cómo puede mantener su código constantemente actualizado y sus confirmaciones válidas?
+
+La siguiente variable es el flujo de trabajo en uso para el proyecto.
+¿Está centralizado, con cada desarrollador teniendo el mismo acceso de escritura a la línea de código principal?
+¿El proyecto tiene un mantenedor o un gerente de integración que verifica todos los parches?
+¿Están todos los parches revisados por pares y aprobados?
+¿Estás involucrado en ese proceso?
+¿Hay un sistema de tenientes en su lugar, y tienes que enviar tu trabajo primero?
+
+El siguiente problema es tu acceso de confirmación.
+El flujo de trabajo requerido para contribuir a un proyecto es muy diferente si tiene acceso de escritura al proyecto que si no lo hace.
+Si no tiene acceso de escritura, ¿cómo prefiere el proyecto aceptar el trabajo contribuido?
+¿Incluso tiene una política?
+¿Cuánto trabajo estás contribuyendo a la vez?
+¿Con qué frecuencia contribuyes?
+
+Todas estas preguntas pueden afectar la forma en que contribuye de manera efectiva a un proyecto y los flujos de trabajo preferidos o disponibles para usted.
+Cubriremos aspectos de cada uno de estos en una serie de casos de uso, pasando de simples a más complejos; debería poder construir los flujos de trabajo específicos que necesita en la práctica a partir de estos ejemplos.
 
 [[_commit_guidelines]]
-==== Commit Guidelines
+==== Pautas de confirmación
 
-Before we start looking at the specific use cases, here's a quick note about commit messages.
-Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier.
-The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches – you can read it in the Git source code in the `Documentation/SubmittingPatches` file.
+Antes de comenzar a buscar casos de uso específicos, aquí hay una nota rápida sobre los mensajes de confirmación.
+Tener una buena guía para crear compromisos y apegarse a ella hace que trabajar con Git y colaborar con otros sea mucho más fácil.
+El proyecto Git proporciona un documento que presenta una serie de buenos consejos para crear compromisos a partir de los cuales enviar parches: puede leerlos en el código fuente de Git en el archivo `Documentation / SubmittingPatches`.
 
 (((git commands, diff, check)))
-First, you don't want to submit any whitespace errors.
-Git provides an easy way to check for this – before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you.
+En primer lugar, no desea enviar ningún error de espacios en blanco.
+Git proporciona una manera fácil de verificar esto: antes de comprometerse, ejecute `git diff --check`, que identifica posibles errores de espacio en blanco y los enumera por usted.
 
 .Output of `git diff --check`.
 image::images/git-diff-check.png[Output of `git diff --check`.]
 
-If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers.
-
-Next, try to make each commit a logically separate changeset.
-If you can, try to make your changes digestible – don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday.
-Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit.
-If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <<_interactive_staging>>).
-The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes.
-This approach also makes it easier to pull out or revert one of the changesets if you need to later.
-<<_rewriting_history>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history before sending the work to someone else.
-
-The last thing to keep in mind is the commit message.
-Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier.
-As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.
-The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior – this is a good guideline to follow.
-It's also a good idea to use the imperative present tense in these messages.
-In other words, use commands.
-Instead of ``I added tests for'' or ``Adding tests for,'' use ``Add tests for.''
-Here is a template originally written by Tim Pope:
+Si ejecuta ese comando antes de confirmar, puede ver si está a punto de cometer problemas de espacio en blanco que pueden molestar a otros desarrolladores.
+
+A continuación, intente hacer que cada commit un conjunto de cambios lógicamente separado.
+Si puede, trate de hacer que sus cambios sean digeribles: no codifique durante un fin de semana entero en cinco asuntos diferentes y luego envíelos todos como un compromiso masivo el lunes.
+Incluso si no confirmas durante el fin de semana, utilice el área de etapas el lunes para dividir su trabajo en al menos una confirmación por cuestión, con un mensaje útil por confirmación.
+Si algunos de los cambios modifican el mismo archivo, intente utilizar `git add --patch` para representar parcialmente los archivos (se detalla en << _ interactive_staging >>).
+La instantánea del proyecto en la punta de la sucursal es idéntica ya sea que realice una confirmación o cinco, siempre que todos los cambios se agreguen en algún momento, así que trate de facilitar las cosas a sus compañeros desarrolladores cuando tengan que revisar sus cambios.
+Este enfoque también hace que sea más fácil retirar o revertir uno de los conjuntos de cambios si lo necesita más adelante.
+<< _ rewriting_history >> describe una serie de útiles trucos de Git para reescribir el historial y organizar de forma interactiva los archivos: use estas herramientas para crear un historial limpio y comprensible antes de enviar el trabajo a otra persona.
+
+Lo último a tener en cuenta es el mensaje de compromiso.
+Tener el hábito de crear mensajes de compromiso de calidad hace que usar y colaborar con Git sea mucho más fácil.
+Como regla general, sus mensajes deben comenzar con una sola línea que no supere los 50 caracteres y que describa el conjunto de cambios de forma concisa, seguido de una línea en blanco, seguida de una explicación más detallada.
+El proyecto Git requiere que la explicación más detallada incluya su motivación para el cambio y contraste su implementación con el comportamiento anterior: esta es una buena guía a seguir.
+También es una buena idea usar el tiempo presente imperativo en estos mensajes.
+En otras palabras, use comandos.
+En lugar de `` agregué pruebas para '' o `` Añadir pruebas para '', use `` Agregar pruebas para ''.
+Aquí hay una plantilla escrita originalmente por Tim Pope:
 
 [source,text]
 -----
-Short (50 chars or less) summary of changes
+Resumen de cambios cortos (50 caracteres o menos)
 
-More detailed explanatory text, if necessary.  Wrap it to
-about 72 characters or so.  In some contexts, the first
-line is treated as the subject of an email and the rest of
-the text as the body.  The blank line separating the
-summary from the body is critical (unless you omit the body
-entirely); tools like rebase can get confused if you run
-the two together.
+Texto explicativo más detallado, si es necesario. Ajustarlo a
+aproximadamente 72 caracteres más o menos. En algunos contextos, el primero
+línea se trata como el tema de un correo electrónico y el resto de
+el texto como el cuerpo. La línea en blanco que separa el
+resumen del cuerpo es crítico (a menos que omita el cuerpo
+enteramente); herramientas como rebase pueden confundirse si ejecuta
+los dos juntos.
 
-Further paragraphs come after blank lines.
+Otros párrafos vienen después de las líneas en blanco.
 
-  - Bullet points are okay, too
+  - Los puntos de viñetas también están bien
 
-  - Typically a hyphen or asterisk is used for the bullet,
-    preceded by a single space, with blank lines in
-    between, but conventions vary here
+  - Típicamente se usa un guión o asterisco para la viñeta,
+    precedido por un solo espacio, con líneas en blanco
+    entre, pero las convenciones varían aquí
 -----
 
-If all your commit messages look like this, things will be a lot easier for you and the developers you work with.
-The Git project has well-formatted commit messages – try running `git log --no-merges` there to see what a nicely formatted project-commit history looks like.
+Si todos sus mensajes de confirmación se ven así, las cosas serán mucho más fáciles para usted y para los desarrolladores con los que trabaja.
+El proyecto Git tiene mensajes de confirmación bien formateados. Intenta ejecutar `git log --no-merges` allí para ver cómo se ve un historial de commit de proyecto muy bien formateado.
 
-In the following examples, and throughout most of this book, for the sake of brevity this book doesn't have nicely-formatted messages like this; instead, we use the `-m` option to `git commit`.
-Do as we say, not as we do.
+En los siguientes ejemplos, y en la mayor parte de este libro, en aras de la brevedad, este libro no tiene mensajes con un formato agradable como este; en cambio, usamos la opción `-m` para` git commit`.
+Haz lo que decimos, no como lo hacemos.
 
 [[_private_team]]
-==== Private Small Team
+==== Pequeño equipo privado
 
 (((contributing, private small team)))
-The simplest setup you're likely to encounter is a private project with one or two other developers.
-``Private,'' in this context, means closed-source – not accessible to the outside world.
-You and the other developers all have push access to the repository.
+La configuración más simple que es probable que encuentre es un proyecto privado con uno o dos desarrolladores más.
+`` Privado '', en este contexto, significa fuente cerrada, no accesible para el mundo exterior.
+Usted y los demás desarrolladores tienen acceso de inserción al repositorio.
 
 In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system.
 You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time.