Full Spanish translation

This commit is contained in:
mgarciaisaia 2014-05-03 17:30:32 -03:00
parent f1686932cb
commit 31ea0cedd0
40 changed files with 2397 additions and 4 deletions

View file

@ -6,12 +6,14 @@ exports.level = {
"en_US": "Diverged History",
"zh_CN": "分散的历史",
"zh_TW": "diverged history",
"es_AR": "Historia divergente",
"de_DE": "Abweichende History"
},
"hint": {
"en_US": "check out the ordering from the goal visualization",
"zh_CN": "检出可视化目标中的顺序",
"zh_TW": "確認視覺化的目標中的順序",
"es_AR": "Prestá atención al oren del objetivo",
"de_DE": "Beachte die Reihenfolge in der Zieldarstellung"
},
"startDialog": {
@ -158,6 +160,149 @@ exports.level = {
}
]
},
"es_AR": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## Trabajo divergente",
"",
"Hasta acá vimos cómo pullear commits de otros y cómo pushear los nuestros. Parece bastante simple, así que ¿cómo puede confundirse tanto la gente?",
"",
"La dificultad viene cuando la historia de los repositorios *diverge*. Antes de entrar en detalles, veamos un ejemplo...",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Imaginate que clonás un repositorio el lunes y empezás a desarrollar algo. Para el viernes ya estás listo para publicar tu trabajo, pero, ¡oh, oh! Tus colegas también escribieron código durante la semana, haciendo que tu trabajo quede desactualizado (y obsoleto). Además, ellos publicaron esos commits en el repositorio remoto, así que ahora *tu* trabajo está basado en una versión *vieja* del proyecto, que ya no le interesa a nadie.",
"",
"En este caso, el comando `git push` es ambiguo. Si corrés `git push`, ¿git debería cambiar el repositorio a como estaba el lunes? ¿Debería tratar de agregar tu código sin eliminar el código nuevo? ¿O debería ignorar completamente tus cambios porque están desactualizados?",
"",
"Como hay tanta ambiguedad en esta situación (en que la historia divirgió), git no te permite pushear tus cambios. En cambio, te fuerza a integrar el último estado del repositorio remoto antes de poder compartir tu trabajo."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"¡Demasiada charla, veámoslo en acción!"
],
"afterMarkdowns": [
"¿Ves? No pasó nada, porque el comando falla. `git push` falla porque `C3`, tu commit más reciente, está basado en el remoto sobre `C1`. El remoto fue actualizado a `C2` desde entonces, por lo que git rechaza tu push"
],
"command": "git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"¿Cómo resolvés esta situación? Es fácil, todo lo que tenés que hacer es basar tu trabajo en la versión más reciente de la rama remota.",
"",
"Hay un par de maneras de hacer esto, pero la más simple es mover tu trabajo haciendo un rebase. Probémoslo a ver cómo se ve."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Ahora, si mejor rebaseamos antes de pushear..."
],
"afterMarkdowns": [
"¡Boom! Actualizamos nuestra representación local del remoto con `git fetch`, rebaseamos nuestro trabajo para reflejar los nuevos cambios del remoto, y después los pusheamos con `git push`"
],
"command": "git fetch; git rebase o/master; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"¿Hay otra manera de actualizar mi trabajo si actualizaron el repositorio remoto? ¡Claro que sí! Veamos cómo hacer lo mismo pero usando `merge`.",
"",
"Por más que `git merge` no mueva tu trabajo (sólo crea un commit de merge), es un modo de decirle a git que integraste todos los cambios del remoto. Esto es porque ahora una rama remota pasó a ser un *ancestro* de tu propia rama, lo que significa que tu commit refleja los cambios de todos los commits de la rama remota.",
"",
"Veamos una muestra..."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Si en lugar de rebasear hacemos un merge..."
],
"afterMarkdowns": [
"¡Boom! Actualizamos nuestra representación local del remoto usando `git fetch`, *mergeamos* el nuevo trabajo junto con el nuestro (para reflejar los nuevos cambios en el remoto), y después los pusheamos usando `git push`"
],
"command": "git fetch; git merge o/master; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"¡Asombroso! ¿Hay forma de hacer esto sin tipear tantos comandos?",
"",
"¡Claro que sí! Ya sabés que `git pull` es simplemente un atajo para hacer fetch y merge. Convenientemente, ¡`git pull --rebase` es un atajo para hacer fetch y rebase!",
"",
"Veamos estos atajos funcionando."
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Primero con `--rebase`..."
],
"afterMarkdowns": [
"¡Igual que antes! Sólo que bastante más corto."
],
"command": "git pull --rebase; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Y ahora un `pull` común"
],
"afterMarkdowns": [
"Otra vez, ¡exactamente lo mismo que antes!"
],
"command": "git pull; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"Toda esta movida de fetchear, rebasear/mergear y pushear es bastante común. En lecciones futuras vamos a ver formas más complejas de estos flujos de trabajo, pero por ahora probemos esto que vimos.",
"",
"Para resolver este nivel, hacé lo siguiente:",
"",
"* Cloná tu repositorio",
"* Simulá algo de trabajo de un colega (1 commit)",
"* Commiteá algo de trabajo propio (1 commit)",
"* Publicá tu trabajo *rebaseando*"
]
}
}
]
},
"zh_TW": {
"childViews": [
{