Travailler sur un développement, un refactoring ou un bugfix impactant.

1) Rappel de fonctionnement
Pour toute activité impactant significativement le code source, il est demandé de travailler sur une branche locale tirée à partir de la branche cible.

Pour rappel, actuellement, les branches cibles sont :

• master – branche de base, servant aux livraisons officielles (pas encore significative)
• proto – branche intégrant les nouvelles évolutions

Par défaut, les développeurs n’ont accès en push sur kercoin.org pour la branche proto uniquement.

Pour toute activité, un bug sur bug.kercoin.org a du être ouvert.

2) Mise en place de l’environnement pour le chantier
On suppose que l’on travaille pour proto et que le “chantier” a pour id bugzilla 123
git checkout proto
git checkout -b dev123

3) Livraison du dev sur la cible
Quand le développement arrive à l’état attendu (et donc que le ticket bugzilla peut avancer à RESOLVED), il faut rapporter sur la branche cible.
Cependant, pour éviter les merges et rendre l’historique git le plus linéaire possible, il faut mettre à jour la branche cible d’abord.
git checkout proto
git pull origin proto

Si des modifications ont été apportées par git pull, alors vous allez devoir rebaser la branche locale avant de merger.
git checkout dev123
git rebase proto

Des conflits de merge peuvent se présenter, à vous de les résoudre car ils porte sur l’application de votre de dev sur la branche ainsi mise à jour. (En effet, le rebase applique les diffs venant d’origin sans conflit puisque les conflits ont déjà été réglés par le développeur ayant pushé auparavant. Ainsi, vous prenez la responsabilité de merger uniquement les différences dont vous êtes l’auteur. Cela apporte de la sécurité au merge puisque vous connaissez sont contenu et son contexte.)

Quand le rebase est terminé, il ne reste plus qu’à merger sur proto :
git checkout proto
git merge dev123

Puis à pusher sur le repository de référence :
git push origin proto

Quand votre développement passe les tests requis, vous pouvez supprimer la branche locale.
git branch -d dev123

A noter que si votre développement est vraiment impactant et que vous souhaitez faire part de vos modifications par lots, vous pouvez répétez ces opérations aux jalons de votre choix. On pourrait cependant imaginer que ce développement aurait pu être découpé en sous-développements – mais tout cela ne relève que de la pure convention !