Half of remote levels translated in french

src/levels/remote/fetchRebase.js

@@ -7,14 +7,16 @@ exports.level = {
     "zh_CN": "分散的历史",
     "zh_TW": "diverged history",
     "es_AR": "Historia divergente",
-    "de_DE": "Abweichende History"
+    "de_DE": "Abweichende History",
+    "fr_FR": "Historique divergeant"
   },
   "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"
+    "de_DE": "Beachte die Reihenfolge in der Zieldarstellung",
+    "fr_FR": "regardez l'ordre dans la fenêtre de visualisation d'objectif"
   },
   "startDialog": {
     "en_US": {
@@ -160,6 +162,149 @@ exports.level = {
         }
       ]
     },
+    "fr_FR": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Travail divergeant",
+              "",
+              "Jusqu'à présent nous avons vu comment rapatrier (`pull`) les commits des collaborateurs et comment envoyer les vôtres (`push`). Cela a l'air simple, alors comment certains peuvent être si perdus ?",
+              "",
+              "La difficulté arrive quand l'historique du dépôt *diverge*. Avant d'aborder les détails de cela, voyons un exemple ...",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Imaginez que vous clonez un dépôt le lundi et commencez à bidouiller une nouvelle fonctionnalité. Le vendredi vous êtes prêt à publier votre fonctionnalité -- mais oh nan ! Vos collègues ont écrit une floppée de code durant la semaine ce qui rend votre fonctionnalité désuète (et obsolète). Ils ont aussi publié sur le dépôt distant partagé, donc maintenant *vôtre* travail est basé sur une *vieille* version du projet qui n'est plus viable.",
+              "",
+              "Dans ce cas, la commande `git push` est ambiguë. Si vous exécutez `git push`, git devrait-il remettre le dépôt distant tel qu'il était lundi ? Doit-il essayer d'ajouter vôtre code sans supprimer le nouveau code ? Ou doit-il totalement ignorer vos changements puisqu'ils ne sont plus à jour ?",
+              "",
+              "Comme il y a trop d'ambiguïté dans cette situation (où l'historique a divergé), git ne vous autorise pas à `push` vos changements. Cela vous force en fait à incorporer le dernier état du dépôt distant avnat de pouvoir partager vôtre travail."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Assez parlé ! Observons cette situation en action"
+            ],
+            "afterMarkdowns": [
+              "Vous voyez ? Rien ne s'est produit car la commande a échoué. `git push` a échoué car vôtre plus récent commit `C3` est basé sur le dépôt distant sur `C1`. Le dépôt distant a depuis été mis à jour avec `C2`, donc git rejette vôtre push."
+            ],
+            "command": "git push",
+            "beforeCommand": "git clone; git fakeTeamwork; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Comment vous résolvez cette situation ? C'est facile, tout ce que vous avez à faire est de baser vôtre travail sur la dernière version de la branche distante.",
+              "",
+              "Il y a plusieurs façons de faire cela, mais la plus directe est de déplacer vôtre travail avec rebase. Allons voir à quoi cela ressemble."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Maintenant si nous rebasons avant de push ..."
+            ],
+            "afterMarkdowns": [
+              "Boum ! Nous avons mis à jour nôtre représentation locale du dépôt avec `git fetch`, rebasé nôtre travail pour refléter les nouveaux changements, et enfin les avons envoyés avec `git push`"
+            ],
+            "command": "git fetch; git rebase o/master; git push",
+            "beforeCommand": "git clone; git fakeTeamwork; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Existe-t-il d'autres façons de mettre à jour nôtre travail quand le répertoire distant a été mis à jour ? Bien sûr ! Faisons la même chose avec `merge` plutôt.",
+              "",
+              "Bien que `git merge` ne déplace pas vôtre travail (et au lieu de cela crée juste un commit de fusion), c'est une façon de dire à git que vous avez incorporé tous les changements du dépôt distant. C'est parce que la branche distante est maitenant une *ancêtre* de vôtre propre branche, ce qui signifie que vos commits reflètent tous les changements faits sur la branche distante.",
+              "",
+              "Voyons une démonstration ..."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Maintenant si nous mergeons avant de rebaser ..."
+            ],
+            "afterMarkdowns": [
+              "Boum ! Nous avons mis à jour nôtre représentation du dépôt distant avec `git fetch`, *fusionné* le nouveau travail dans nôtre travail (pour refléter les nouveaux changements du dépôt distant), et les avons ensuite envoyés avec `git push`"
+            ],
+            "command": "git fetch; git merge o/master; git push",
+            "beforeCommand": "git clone; git fakeTeamwork; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Impressionnant ! Existe-t-il une façon de faire sans taper autant de commandes ?",
+              "",
+              "Bien sûr -- vous savez déjà que `git pull` est simplement un raccourci pour un fetch puis un merge. De manière assez pratique, `git pull --rebase` est un raccourci pour un fetch puis un rebase !",
+              "",
+              "Voyons ce raccourci au travail."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Premièrement avec  `--rebase`..."
+            ],
+            "afterMarkdowns": [
+              "Comme avant ! Juste un peu plus court."
+            ],
+            "command": "git pull --rebase; git push",
+            "beforeCommand": "git clone; git fakeTeamwork; git commit"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Et maintenant avec un `pull` normal"
+            ],
+            "afterMarkdowns": [
+              "Encore une fois, exactement la même chose qu'avant !"
+            ],
+            "command": "git pull; git push",
+            "beforeCommand": "git clone; git fakeTeamwork; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Cette succession de fetch, rebase/merge, et push est assez commune. Dans les leçons suivantes, nous allons explorer plus profondément cette façon de d'enchaîner les commandes, mais essayons plutôt cela maintenant.",
+              "",
+              "Pour finir ce niveau, réalisez les étapes suivantes :",
+              "",
+              "* Clonez vôtre dépôt",
+              "* Simuler un travail d'équipe (1 commit)",
+              "* Commitez un peu de vôtre travail (1 commit)",
+              "* Publiez vôtre travail avec *rebase*"
+            ]
+          }
+        }
+      ]
+    },
     "es_AR": {
       "childViews": [
         {

src/levels/remote/mergeManyFeatures.js

@@ -7,14 +7,16 @@ exports.level = {
     "zh_CN": "和远端合并",
     "zh_TW": "merge with remotes",
     "es_AR": "Mergeando con los remotos",
-    "de_DE": "Änderungen vom Remote zusammenführen"
+    "de_DE": "Änderungen vom Remote zusammenführen",
+    "fr_FR": "Fusionner avec les branches distantes"
   },
   "hint": {
     "en_US": "Pay attention to the goal tree!",
     "zh_CN": "注意目标树!",
     "zh_TW": "注意最後要完成的目標！",
     "es_AR": "¡Prestá atención al árbol final!",
-    "de_DE": "Beachte den Ziel-Baum!"
+    "de_DE": "Beachte den Ziel-Baum!",
+    "fr_FR": "Respectez l'arbre représentant l'objectif !"
   },
   "compareOnlyMaster": true,
   "startDialog": {
@@ -63,6 +65,51 @@ exports.level = {
         }
       ]
     },
+    "fr_FR": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Pourquoi pas merge ?",
+              "",
+              "Dans le but d'envoyer de nouvelles modifications sur le dépôt distant, tout ce que vous avez à faire est *incorporer* les derniers changements dans ce dépôt. Cela signifie que vous pouvez faire un rebase *ou* merge dans la branche distante (e.g. `o/master`).",
+              "",
+              "Donc si l'on peut faire les deux méthodes, pourquoi les leçons se sont (re)basées (!) sur rebase jusqu'à présent ? Pourquoi n'aime-t-on pas `merge` dans les branches distantes ?",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Il y a beaucoup de débats à propos du compromis entre l'utilisation de merge et rebase dans la communauté des développeurs. Voici les principaux arguments pour / contre rebase:",
+              "",
+              "Pour :",
+              "",
+              "* Rebase rend votre arbre de commits très propre puisqu'il ressemble à une ligne droite.",
+              "",
+              "Contre :",
+              "",
+              "* Rebase modifie l'historique (apparent) de l'arbre des commits.",
+              "",
+              "Par exemple, le commit `C1` peut être rebasé *après* `C3`. Cela fait croire que le travail de `C1'` est arrivé après `C3` alors qu'en réalité il était complétement avant.",
+              "",
+              "Certains développeurs aiment préserver l'historique et préfèrent donc merge. Les autres (comme moi) préfèrent avoir un arbre des commits propre et préfèrent rebase. C'est une question de goût :D"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Pour ce niveau, essayons de résoudre le niveau précédent, mais avec *merge* plutôt. Cela peut être un peu périlleux mais cela illustre bien le problème."
+            ]
+          }
+        }
+      ]
+    },
     "es_AR": {
       "childViews": [
         {

src/levels/remote/pull.js

@@ -7,14 +7,16 @@ exports.level = {
     "zh_CN": "Git Pull",
     "zh_TW": "git pull'",
     "es_AR": "git pull",
-    "de_DE": "Git Pull"
+    "de_DE": "Git Pull",
+    "fr_FR": "Git pull"
   },
   "hint": {
     "en_US": "Just run git pull!",
     "zh_CN": "只要运行 git pull 命令!",
     "zh_TW": "只要下 git pull 這個指令即可",
     "es_AR": "Simplemente ¡hacé git pull!",
-    "de_DE": "Führe einfach git pull aus."
+    "de_DE": "Führe einfach git pull aus.",
+    "fr_FR": "Utilisez facilement git pull !"
   },
   "startDialog": {
     "en_US": {
@@ -76,6 +78,65 @@ exports.level = {
         }
       ]
     },
+    "fr_FR": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Git Pull",
+              "",
+              "Maintenant que vous avez vu comment rapatriez des données depuis un dépôt distant avec `git fetch`, mettons à jour notre copie de travail pour refléter ces changements !",
+              "",
+              "Il existe en fait beaucoup de façons de faire cela -- une fois que vous avez de nouveaux commits disponibles localements, vous pouvez les incorporer comme s'ils étaient des commits normaux d'autres branches. Cela signifie que pourriez juste exécuter des commandes comme :",
+              "",
+              "* `git cherry-pick o/master`",
+              "* `git rebase o/master`",
+              "* `git merge o/master`",
+              "* etc., etc.",
+              "",
+              "En fait, le principe de *rapatrier* (fetch) les branches distantes puis les *fusionner* (merge) est si commun que git a en réalité une commande pour faire les deux à la fois ! Cette commande est `git pull`."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Voyons d'abord un `fetch` puis un `merge` exécutés séquentiellement"
+            ],
+            "afterMarkdowns": [
+              "Boum -- nous avons téléchargé `C3` avec un `fetch` et ensuite nous avons fusionné ce travail dans notre copie avec `git merge o/master`. Maintenant nôtre branche `master` reflète le nouveau travail du dépôt distant (dans ce cas, nommé `origin`)"
+            ],
+            "command": "git fetch; git merge o/master",
+            "beforeCommand": "git clone; git commit; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Que se passerait-il si nous utilisions plutôt `git pull` ?"
+            ],
+            "afterMarkdowns": [
+              "La même chose ! Cela devrait maintenant être clair que `git pull` est surtout un raccourci pour `git fetch` suivi d'un merge de toutes les branches qui viennent d'avoir un fetch."
+            ],
+            "command": "git pull",
+            "beforeCommand": "git clone; git commit; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Nous allons explorer les détails de `git pull` plus tard (y compris options et arguments), mais essayons d'abord cela dans notre niveau.",
+              "",
+              "Rappelez-vous -- vous pouvez aussi résoudre ce niveau avec `fetch` et `merge`, mais cela vous coûtera une commande supplémentaire :P"
+            ]
+          }
+        }
+      ]
+    },
     "es_AR": {
       "childViews": [
         {

src/levels/remote/pullArgs.js

@@ -7,14 +7,16 @@ exports.level = {
     "zh_CN": "Pull 的参数",
     "zh_TW": "pull 的參數",
     "es_AR": "Parámetros de pull",
-    "de_DE": "Optionen für Pull"
+    "de_DE": "Optionen für Pull",
+    "fr_FR": "Arguments de pull"
   },
   "hint": {
     "en_US": "Remember that you can create new local branches with fetch/pull arguments",
     "zh_CN": "记住, 你可以通过 fetch/pull 创建本地分支",
     "zh_TW": "記住，你可以透過 fetch 以及 pull 來建立一個新的 local 的 branch",
     "es_AR": "Acordate de que podés crear nuevas ramas locales usando los parámetros de fetch/pull",
-    "de_DE": "Du kannst neue lokale Branches mittels fetch / pull erstellen"
+    "de_DE": "Du kannst neue lokale Branches mittels fetch / pull erstellen",
+    "fr_FR": "Vous pouvez aussi créer une nouvelle branche locale avec les arguments de fetch/pull"
   },
   "startDialog": {
     "en_US": {
@@ -91,6 +93,80 @@ exports.level = {
         }
       ]
     },
+    "fr_FR": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Les arguments de git pull",
+              "",
+              "Maintenant que vous savez presque *tout* ce qu'il y a à savoir à propos des arguments de `git fetch` et `git push`, il n'y a presque rien de restant à découvrir avec git pull :)",
+              "",
+              "C'est parce que git pull est au bout du compte *réellement* juste un raccourci pour un merge suivi d'un merge pour tout ce qui vient d'être rapatrié (par le fetch). Vous pouvez y pensez comme exécuter git fetch avec les *mêmes* arguments specifiés et ensuite fusionner avec là où ces commits sont arrivés.",
+              "",
+              "Cela fonctionne même quand vous utilisez des arguments très compliqués. Voyons quelques exemples :"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Voici quelques commandes équivalentes dans git :",
+              "",
+              "`git pull  origin foo` est équivalent à :",
+              "",
+              "`git fetch origin foo; git merge o/foo`",
+              "",
+              "Et ...",
+              "",
+              "`git pull  origin bar~1:bugFix` est équivalent à :",
+              "",
+              "`git fetch origin bar~1:bugFix; git merge bugFix`",
+              "",
+              "Vous voyez ? git pull est vraiment simplement un raccourci pour fetch + merge, et tout ce dont git pull s'occupe est la destination des commits (l'argument `destination` qu'il utilise durant le fetch).",
+              "",
+              "Voyons une démonstration :"
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Si nous précisons l'emplacement à rappatrier, tout se passe comme avant avec fetch mais nous fusionnons avec tout ce qui a été rapatrié"
+            ],
+            "afterMarkdowns": [
+              "Vu ? en précisant `master` nous avons téléchargé les commits dans `o/master` comme d'habitude. Puis nous avons fusionné `o/master` avec là où nous sommes, *sans se soucier* de la branche courante."
+            ],
+            "command": "git pull origin master",
+            "beforeCommand": "git clone; go -b bar; git commit; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Cela fonctionne-t-il avec une source et une destination aussi ? Et oui ! Voyons cela :"
+            ],
+            "afterMarkdowns": [
+              "Wow, c'est énorme en une commande. Nous avons créé une brance locale nommée `foo`, téléchargé les commits depuis la branche master distante dans `foo`, et ensuite fusionné cette branche dans notre branche actuelle de travail `bar`. It's over 9000!!!"
+            ],
+            "command": "git pull origin master:foo",
+            "beforeCommand": "git clone; git fakeTeamwork; go -b bar; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Ok pour finir ce niveau, atteignez l'état décrit dans la visualtion de l'objectif. Vous aurez besoin de télécharger quelques commits, de faire quelques nouvelles branches, et de fusionner ces branches dans d'autres branches, mais cela ne devrait pas utiliser trop de commandes :P"
+            ]
+          }
+        }
+      ]
+    },
     "es_AR": {
       "childViews": [
         {