[Perkamon-l10n-fr] Gestion des branches

[Denis Barbier]

Bonjour,

Je vais expliquer dans ce message comment sont gérées les mises à jour
des branches 3.2x. Vous n'êtes pas obligés de lire si ça ne vous
intéresse pas, c'est purement informatif.
Pour mettre à jour ces branches, il faut évidemment commencer par
créer ces branches localement :
   $ for i in 5 6 7; do git checkout -b 3.2$i origin/3.2$i; done

Quand la traduction de la 3.28 est complète, je fusionne ces branches
avec master
  $ h=$(git rev-list -n 1 master); for i in 5 6 7; do \
       git checkout 3.2$i; \
       git merge -s ours $h; \
    done

L'option « -s ours » de merge est très importante, elle signifie qu'on
garde les fichiers de la branche 3.2x inchangés, mais on prétend avoir
fait un merge.
Comme vous le voyez dans l'historique, je modifie le message du commit
pour faire apparaitre en clair la commande utilisée.

Tous les commits qui sont ensuite faits dans master sont des
corrections de traduction, jusqu'à ce qu'on bascule les pages en
anglais vers la version en développement de man-pages.
Ces corrections sont répercutées dans les branches en utilisant la commande
  $ for i in 5 6 7; do \
       git checkout 3.2$i; \
       git merge -X ours master; \
    done

Lors de la fusion entre une branche 3.2$i et master, l'algorithme de
fusion verra qu'un merge a déjà eu lieu, et il n'appliquera que les
changements qui ont été introduits ensuite. C'est tout l'intérêt du
1er merge décrit ci-dessus.
Cette fois, ce n'est plus « -s ours » mais « -X ours ». Le merge
utilise la stratégie par défaut (recursive), mais avec l'option « ours
». C'est une approche conservative : en cas de conflit, on garde les
bouts actuels inchangés. Ainsi, les corrections qui s'appliquent sans
conflits sont répercutées, mais pas celles qui ont engendré des
conflits.
Cela permet de répercuter les corrections de traduction sur les
différentes branches avec un coût quasi-nul. On pourrait faire mieux
en résolvant les conflits, mais cela risque d'alourdir
considérablement la charge de travail, je n'ai pas trop envie de le
faire.
Voilà, avec ces explications, vous devriez maintenant mieux comprendre
pourquoi j'insiste sur la séparation des commits entre les mises à
jour et les corrections.

Denis