Skip to content
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.

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

Corregida redacción en Español del capítulo 5.2 - Contribuyendo a un … #171

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

leandrocaplan
Copy link

English

I have been correcting what I could in the Spanish writing of chapter 5.2 Git in Distributed Environments - Contributing to a Project. So far, it seems to have been translated by an automaton several years ago, without the use of artificial intelligence.
In this way, many key terms, such as 'push,' were translated, for example, as 'press' or 'propel.' The branch name 'origin/master' was translated as 'origen/maestro.'
It is evident, therefore, that the person who made this translation did not even bother to review these kinds of issues before publishing them in this edition of the book in Spanish.
I propose to upload an updated version of the chapter's writing, better reviewed than the previous one.

Español

Estuve corrigiendo en la medidaque pude, la redacción en Español del capítulo 5.2 Git en entornos distribuidos - Contribuyendo a un Proyecto. Hasta el momento, parece haber sido traducido por un autómata, varios años atrás, sin utilización de inteligencia artificial.
De esta forma, muchas palabras claves como 'push', fueron traducidas por ejemplo, como 'presionar' o 'impulsar'. La denominación de la rama 'origin/master', se encontraba traducida como 'origen/maestro'.
Es evidente así, que la persona que hizo esta traducción, ni siquiera se molestó en revisar este tipo de cuestiones antes de publicarlas en esta edición del libro en Español.
Propongo subir entonces, una actualización de la redacción de este capítulo, mejor revisada que la anterior.

La razón es que si el trabajo no se acepta o se selecciona con una cereza, no es necesario rebobinar la rama maestra.
Entonces necesitas publicar tu trabajo hasta esa nueva URL.
Es más fácil publicar 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 efectua un cherry-pick, no es necesario rebobinar la rama maestra.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... una selección selectiva ...

@@ -554,8 +554,8 @@ Jessica Smith (2):

La salida se puede enviar al mantenedor, le dice de dónde se ramificó el trabajo, resume los compromisos y dice de dónde sacar este trabajo.

En un proyecto para el cual no eres el mantenedor, generalmente es más fácil tener una rama como `master` siempre rastreando` 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.
En un proyecto para el cual no eres el administrdor, generalmente es más fácil tener una rama como `master` siempre rastreando` origin/master` y hacer tu trabajo en ramas de tema que puedes descartar fácilmente si son rechazadas.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"mantenedor" aparece en la RAE (aunque suene medio raro); administrdor mal escrito

@@ -101,7 +101,7 @@ Usted y los demás desarrolladores son los únicos que tienen acceso de inserci
En este entorno, puede seguir un flujo de trabajo similar a lo que podría hacer al usar Subversion u otro sistema centralizado.
Aún obtiene las ventajas de cosas como el compromiso fuera de línea y una bifurcación y fusión mucho más simples, pero el flujo de trabajo puede ser muy similar; la principal diferencia es que las fusiones ocurren en el lado del cliente en lugar del servidor en el momento de la confirmación.
Veamos cómo se vería cuando dos desarrolladores comiencen a trabajar juntos con un repositorio compartido.
El primer desarrollador, John, clona el repositorio, hace un cambio y se compromete localmente.
El primer desarrollador, John, clona el repositorio, realiza un commit y se compromete localmente.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No estoy seguro si es mejor dejar commit sin traducir o seeguir los términos usados en https://git-scm.com/docs/git-commit/es

@leandrocaplan
Copy link
Author

@hasecilu
¡Gracias por la devolución! En cuanto tenga un tiempo, trabajaré un poco mas sobre el texto considerando estas cuestiones, y haré una nueva publicación, de forma que se pueda evaluar si estas correcciones, ameritan ser incorporadas al libro en Español.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants