Hugo/doc/translation
J'ai traduit la documentation utilisateur qui n'avait pas encore été traduite.
Merge request reports
Activity
@HugoTrentesaux pour éviter d'encombrer l'historique il est temps de réorganiser tes commits avec un rebase interactif :)
Profite en pour donner plus de précisions, je te propose les nom de commit suivants
[docs] user: translate documentation in english [docs] dev: proofreading english translation [docs] dev: proofreading french version
Notamment tu a 2 commits ou tu touche a la doc user FR -> faut les rassembler en 1 seul. Il faut préciser le scope, la convention c'est du préciser le type de doc après le type du commit suivie de ":" ;)
Pour faire tout ceci il te faut faire un rebase interactif de ta branche sur elle même sur 4 commits de profondeur :
git rebase -i HEAD~4ou
git rebase -i HEAD^^^^Je t'invite a lire un tuto sur le rebasage git :)
@librelois Done. Mais j'ai triché, j'ai pas fait le rebase en ligne de commande
-
@HugoTrentesaux bravo tu a obtenu le résultat attendu, c'est tout ce qui compte pour moi :)
Par curiosité tu a utilisé quel logiciel pour faire ça sans la ligne de commande ?
Je mergerai demain soir, la j'ai étteint mon poste de dev ^^
added 5 commits
-
8be880cd...3d6b29bc - 2 commits from branch
dev - 9c3d315f - [docs] whole: proofreading french version
- fea97efb - [docs] dev: proofreading english translation
- 36a6fc96 - [docs] user: translate documentation in english
Toggle commit list-
8be880cd...3d6b29bc - 2 commits from branch
-
@HugoTrentesaux j'ai mis a jours ta branche sur dev puis j'ai mergé.
Merci beaucoup pour cette contribution ^^
La prochaine fois je te laisserai essayer de mettre a jours ta branche toi même :)
-
J'ai utilisé le plugin "git" pour atom, qui me permet de gérer les commits visuellement.
Que d'habitudes à prendre ! Et cette branche dev qui avance toute seule :) j'étais à jour avec elle quand j'ai soumis la merge request mais je n'ai pas pensé à regarder son état quand j'ai réorganisé les commits.
Est-ce que tu fais un rebase systématiquement sur dev ou est-ce que tu as un outil pour visualiser l'avancement des différentes branches ?
-
Que d'habitudes à prendre ! Et cette branche dev qui avance toute seule :) j'étais à jour avec elle quand j'ai soumis la merge request mais je n'ai pas pensé à regarder son état quand j'ai réorganisé les commits.
Est-ce que tu fais un rebase systématiquement sur dev ou est-ce que tu as un outil pour visualiser l'avancement des différentes branches ?
@HugoTrentesaux Oui il faut mettre a jours tes branches par rapport à dev le plus souvent possible car dev avance fréquemment. A minima lorsque tu travaille sur une branche a toi nommée YOUR_BRANCH il faut au préalable mettre a jours ta branche sur dev comme suit :
git checkout dev git pull git checkout YOUR_BRANCH git rebase devEn cas de conflits pendant le rebase que tu n'arriverai pas a résoudre tout seul, il faut me contacter (m'indiquer le hash du commit de ta branche au moment du rebase pour que je puisse reproduire le rebase et voir les conflits en question). En attendant que je réponde, tu peut "abort" ton rebase et travailler sur ta branche sans te mettre a jours :
git rebase --abortEn cas de doute sur le fait que tu soit a jours ou non, tu peut faire un rebase dans tout les cas, si tu est déjà a jours ça ne fera rien :)
Si tu veut amender la documentation avec ce que je dit la, c'est une contribution bienvenue ;)
Edited by Éloïs -
Voici ma proposition : 9f17015c
J'hésitais à combiner avec la partie "Comment merger ma contribution" dans "conventions-git". Est-ce que tu préfère que je soumette une nouvelle merge request et qu'on en discute en dessous ou est-ce que j'attends d'avoir une version quasi avec également la traduction en anglais ?
-
Merci @HugoTrentesaux , oui je préfère que tu ouvre une MR dés maintenant comme ça je pourrais te faire des retours précis directement dans l'onglet "change" sous la ligne concernée.
En fait on peut soumettre une MR même s'il y a des conflits, la MR créer un espace ou l'on peut notamment discuter de la résolution de ces conflits :)
De plus, la mise a jours sur la branche dev ne doit pas ce faire que lors de la création de la MR, ça doit être fait par le contributeur à chaque fois qu'il traite les retours d'un reviewer. De plus, une fois tout les retours traités, il conviens de retager le reviewer en question pour qu'il vérifie que ces retours ont été traités d'une façon satisfaisante.
Enfin, la plupart du temps il conviens de créer la MR a partir d'une issue, cela créer également la branche de travail du contributeur, il soumet donc la MR avant même de commencer la tache associée ;)
Du coup il ne faut pas voir les MR comme "je soumet un truc que j'ai fait" mais comme un processus qui commence dés l'(auto-)assignation d'une tache à un contributeur et qui se poursuit jusqu'a la fusion dans
dev(ou l'abandon de la MR).Edited by Éloïs