Skip to content

Partial 3 update contributing.asc #101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
andres-mancera merged 1 commit into from
Feb 26, 2018
Merged

Partial 3 update contributing.asc #101

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 50 additions & 50 deletions book/05-distributed-git/sections/contributing.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -386,7 +386,7 @@ From jessica@githost:simplegit
* [new branch] featureBee -> origin/featureBee
-----

Jessica can now merge this into the work she did with `git merge`:
Jessica ahora puede fusionar esto en el trabajo que hizo con `git merge`:

[source,console]
-----
Expand All @@ -397,8 +397,8 @@ Merge made by recursive.
1 files changed, 4 insertions(+), 0 deletions(-)
-----

There is a bit of a problem – she needs to push the merged work in her `featureB` branch to the `featureBee` branch on the server.
She can do so by specifying the local branch followed by a colon (:) followed by the remote branch to the `git push` command:
Existe un pequeño problema: necesita insertar el trabajo combinado en su rama `featureB` en la rama` featureBee` del servidor.
Ella puede hacerlo especificando la rama local seguida de dos puntos (:) seguido de la rama remota al comando `git push`:

[source,console]
-----
Expand All @@ -408,12 +408,12 @@ To jessica@githost:simplegit.git
fba9af8..cd685d1 featureB -> featureBee
-----

This is called a _refspec_.
See <<_refspec>> for a more detailed discussion of Git refspecs and different things you can do with them.
Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later.
Esto se llama _refspec_.
Ver << _ refspec >> para una discusión más detallada de las referencias de Git y diferentes cosas que puedes hacer con ellas.
También observe la bandera `-u`; esto es la abreviatura de `--set-upstream`, que configura las ramas para empujar y tirar más fácilmente más tarde.

Next, John e-mails Jessica to say he's pushed some changes to the `featureA` branch and asks her to verify them.
She runs a `git fetch` to pull down those changes:
Luego, John envía un correo electrónico a Jessica para decirle que ha enviado algunos cambios a la rama `featureA` y le pide que los verifique.
Ella ejecuta un `git fetch` para bajar esos cambios:

[source,console]
-----
Expand All @@ -423,7 +423,7 @@ From jessica@githost:simplegit
3300904..aad881d featureA -> origin/featureA
-----

Then, she can see what has been changed with `git log`:
Luego, ella puede ver qué se ha cambiado con `git log`:

[source,console]
-----
Expand All @@ -435,7 +435,7 @@ Date: Fri May 29 19:57:33 2009 -0700
changed log output to 30 from 25
-----

Finally, she merges John's work into her own `featureA` branch:
Finalmente, fusiona el trabajo de John en su propia rama `featureA`:

[source,console]
-----
Expand All @@ -448,7 +448,7 @@ Fast forward
1 files changed, 9 insertions(+), 1 deletions(-)
-----

Jessica wants to tweak something, so she commits again and then pushes this back up to the server:
Jessica quiere modificar algo, por lo que se compromete de nuevo y luego lo envía de vuelta al servidor:

[source,console]
-----
Expand All @@ -461,36 +461,36 @@ To jessica@githost:simplegit.git
3300904..774b3ed featureA -> featureA
-----

Jessica's commit history now looks something like this:
El historial de compromiso de Jessica ahora se ve así:

.Jessica's history after committing on a feature branch.
image::images/managed-team-2.png[Jessica's history after committing on a feature branch.]

Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline.
After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this:
Jessica, Josie y John informan a los integradores que las ramas `featureA` y` featureBee` en el servidor están listas para su integración en la línea principal.
Después de que los integradores fusionen estas ramas en la línea principal, una búsqueda reducirá la nueva confirmación de fusión, haciendo que el historial se vea así:

.Jessica's history after merging both her topic branches.
image::images/managed-team-3.png[Jessica's history after merging both her topic branches.]

Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process.
The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git.
The sequence for the workflow you saw here is something like this:
Muchos grupos cambian a Git debido a esta capacidad de tener varios equipos trabajando en paralelo, fusionando las diferentes líneas de trabajo al final del proceso.
La capacidad de los subgrupos más pequeños de un equipo para colaborar a través de sucursales remotas sin necesariamente tener que involucrar o impedir a todo el equipo es un gran beneficio de Git.
La secuencia del flujo de trabajo que vio aquí es algo como esto:

.Basic sequence of this managed-team workflow.
image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.]

[[_public_project]]
==== Forked Public Project
==== Proyecto público bifurcado

(((contributing, public small project)))
Contributing to public projects is a bit different.
Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way.
This first example describes contributing via forking on Git hosts that support easy forking.
Many hosting sites support this (including GitHub, BitBucket, Google Code, repo.or.cz, and others), and many project maintainers expect this style of contribution.
The next section deals with projects that prefer to accept contributed patches via e-mail.
Contribuir a proyectos públicos es un poco diferente.
Como no tiene los permisos para actualizar directamente las ramas en el proyecto, debe obtener el trabajo de otra manera.
Este primer ejemplo describe la contribución mediante bifurcación en hosts Git que admiten bifurcación fácil.
Muchos sitios de alojamiento admiten esto (incluidos GitHub, BitBucket, Google Code, repo.or.cz y otros), y muchos mantenedores de proyectos esperan este estilo de contribución.
La siguiente sección trata de proyectos que prefieren aceptar parches contribuidos por correo electrónico.

First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there.
The sequence looks basically like this:
En primer lugar, es probable que desee clonar el repositorio principal, crear una rama de tema para el parche o la serie de parches que planea contribuir y hacer su trabajo allí.
La secuencia se ve básicamente así:

[source,console]
-----
Expand All @@ -503,35 +503,35 @@ $ git commit
$ git commit
-----

[NOTE]
[NOTA]
====
You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review – see <<_rewriting_history>> for more information about interactive rebasing.
Puede usar `rebase -i` para reducir su trabajo a una única confirmación, o reorganizar el trabajo en las confirmaciones para que el desarrollador pueda revisar el parche más fácilmente. Consulte << _ rewriting_history >> para obtener más información sobre el rebase interactivo.
====

When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project.
You then need to add in this new repository URL as a second remote, in this case named `myfork`:
Cuando finalice el trabajo de sucursal y esté listo para contribuir con los mantenedores, vaya a la página original del proyecto y haga clic en el botón `` Tenedor '', creando su propio tenedor escribible del proyecto.
Luego debe agregar este nuevo URL de repositorio como segundo control remoto, en este caso llamado `myfork`:

[source,console]
-----
$ git remote add myfork (url)
-----

Then you need to push your work up to it.
It's easiest to push the topic branch you're working on up to your repository, rather than merging into your master branch and pushing that up.
The reason is that if the work isn't accepted or is cherry picked, you don't have to rewind your master branch.
If the maintainers merge, rebase, or cherry-pick your work, you'll eventually get it back via pulling from their repository anyhow:
Entonces necesitas impulsar tu trabajo hasta eso.
Es más fácil impulsar la rama de tema en la que está trabajando hasta su repositorio, en lugar de fusionarse con su rama principal y aumentarla.
La razón es que si el trabajo no se acepta o se selecciona con una cereza, no es necesario rebobinar la rama maestra.
Si los mantenedores se fusionan, redimensionan o seleccionan su trabajo, eventualmente lo recuperará a través de su repositorio de todas maneras:

[source,console]
-----
$ git push -u myfork featureA
-----

(((git commands, request-pull)))
When your work has been pushed up to your fork, you need to notify the maintainer.
This is often called a pull request, and you can either generate it via the website – GitHub has its own Pull Request mechanism that we'll go over in <<_github>> – or you can run the `git request-pull` command and e-mail the output to the project maintainer manually.
Cuando su trabajo ha sido empujado hacia su tenedor, debe notificar al mantenedor.
Esto a menudo se denomina solicitud de extracción, y puedes generarlo a través del sitio web: GitHub tiene su propio mecanismo de solicitud de extracción que veremos en << _ github >> o puedes ejecutar el comando `git request-pull` y envíe por correo electrónico la salida al mantenedor del proyecto de forma manual.

The `request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you're asking to be pulled in.
For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed up, she can run this:
El comando `request-pull` toma la rama base en la que desea que se saque su rama de tema y la URL del repositorio de Git de la que desea que extraigan, y genera un resumen de todos los cambios que está solicitando.
Por ejemplo, si Jessica quiere enviar a John una solicitud de extracción, y ella ha hecho dos commits en la rama de temas que acaba de subir, puede ejecutar esto:

[source,console]
-----
Expand All @@ -552,11 +552,11 @@ Jessica Smith (2):
1 files changed, 9 insertions(+), 1 deletions(-)
-----

The output can be sent to the maintainer–it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from.
La salida se puede enviar al mantenedor, les dice de dónde se ramificó el trabajo, resume los compromisos y dice de dónde sacar este trabajo.

On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected.
Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly.
For example, if you want to submit a second topic of work to the project, don't continue working on the topic branch you just pushed up – start over from the main repository's `master` branch:
En un proyecto para el cual no eres el mantenedor, generalmente es más fácil tener una rama como `master` siempre rastrea` origin / master` y hacer tu trabajo en ramas de tema que puedes descartar fácilmente si son rechazadas.
Tener temas de trabajo aislados en las ramas temáticas también facilita la tarea de volver a establecer una base de trabajo si la punta del repositorio principal se ha movido mientras tanto y sus confirmaciones ya no se aplican limpiamente.
Por ejemplo, si desea enviar un segundo tema de trabajo al proyecto, no continúe trabajando en la rama de tema que acaba de crear: vuelva a comenzar desde la rama `master` del repositorio principal:

[source,console]
-----
Expand All @@ -568,13 +568,13 @@ $ git push myfork featureB
$ git fetch origin
-----

Now, each of your topics is contained within a silo – similar to a patch queue – that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so:
Ahora, cada uno de sus temas está contenido dentro de un silo, similar a una fila de parches, que puede volver a escribir, volver a establecer y modificar sin que los temas interfieran o se interrelacionen entre sí, de la siguiente manera:

.Initial commit history with `featureB` work.
image::images/public-small-1.png[Initial commit history with `featureB` work.]

Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges.
In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes:
Digamos que el mantenedor del proyecto ha sacado otros parches y ha probado su primera sucursal, pero ya no se fusiona de manera limpia.
En este caso, puede tratar de volver a establecer la base de esa rama sobre 'origin / master', resolver los conflictos del mantenedor y luego volver a enviar los cambios:

[source,console]
-----
Expand All @@ -583,18 +583,18 @@ $ git rebase origin/master
$ git push -f myfork featureA
-----

This rewrites your history to now look like <<psp_b>>.
Esto reescribe tu historial para que ahora parezca << psp_b >>.

[[psp_b]]
.Commit history after `featureA` work.
image::images/public-small-2.png[Commit history after `featureA` work.]

Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it.
An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`).
Debido a que rebasaste la rama, debes especificar el `-f` en tu comando push para poder reemplazar la rama` featureA` en el servidor con una confirmación que no sea un descendiente de ella.
Una alternativa sería llevar este nuevo trabajo a una rama diferente en el servidor (tal vez llamada `featureAv2`).

Let's look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail.
You'll also take this opportunity to move the work to be based off the project's current `master` branch.
You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that up as a new branch:
Veamos un escenario más posible: el mantenedor ha observado el trabajo en su segunda sucursal y le gusta el concepto, pero le gustaría que cambie un detalle de implementación.
También aprovechará esta oportunidad para mover el trabajo basado en la rama `maestra 'actual del proyecto.
Usted inicia una nueva sucursal basada en la rama actual de 'origen / maestro', aplasta los cambios `featureB` allí, resuelve cualquier conflicto, hace que la implementación cambie, y luego lo empuja hacia arriba como una nueva sucursal:

(((git commands, merge, squash)))
[source,console]
Expand Down