Depuis l’automne passé, les équipes de développement chez Absolunet utilisent Git à temps plein. Sans réserve, je peux dire que l’on vit le rêve Git à temps plein. Branches à volonté et modèle de travail asynchrone et déconnecté sont au rendez-vous.
Ce que je suis sur le point de documenter est un truc que j’ai dernièrement sorti du derrière de ma manche afin de me sortir du pétrin. Lorsque je dis que je me suis sorti du pétrin, il s’agit de se mettre dans le même état d’esprit que l’image ci-dessous.
Rien n’arrive pour rien dans ce beau monde. La réalité vient parfois vous frapper en plein visage. Dans mon cas, il s’agit de la réintégration d’une branche restée en développement pendant trop longtemps sans être réintégrée graduellement.
Je peux vous dire que ça a été pénible jusqu’à la mise en ligne.
Un seul commit
En théorie, il ne devrait pas y avoir d’obstacles à réintégrer une branche, peu importe la période de temps où le développement s’est fait en parallèle. Point à la ligne. Les révisions branchées sont appliquées par-dessus celles où vous désirez réintégrer. Validez les conflits, testez votre code et c’est la fin de l’histoire.
Là où la réalité est venue me rattraper, est que lors de la réintégration de cette branche, une très grande majorité des fichiers nouvellement ajoutés lors du développement en question était considérée en conflit. Cela ne devrait pas se passer ainsi, n’est-ce pas?
Or, il s’avère que la source de cet incident est relativement anodine, mais a une importance capitale. Par erreur, une réintégration de la branche de développement avait été effectuée et soumise à l’historique de développement commun. Lorsque nous avions réalisé notre bourde, le commit en question avait été annulé (revert).
Vous me voyez venir? Tous les changements, même s’ils sont des fichiers nouveaux vis-à-vis la branche dans laquelle je tentais de réintégrer, puisqu’ils avaient été précédemment annulés Git ne pouvait déterminer ce qu’ils devaient conserver comme modification.
Ce qui fait mal dans toute l’opération est le volume de fichiers à résoudre. Il y en avait des centaines. En plus de cela, les changements étaient dispersés à travers quelques centaines de commits et une bonne proportion d’entre eux contenaient des changements mixtes. C’est à dire des fichiers qui avaient évolué à la fois sur la branche stable et celle de développement.
Aux grands maux, les grands moyens
Je ne vais pas raconter d’histoire. La solution que j’ai retenue est loin d’être élégante et très loin d’un modèle reposant sur les bonnes pratiques du versionnage de code source.
Ce que j’ai fait ressemble à ça :
- prendre une copie de la branche master
- coller son contenu dans ma branche de développement.
Je dois avouer que ce n’est pas très élégant.
Toutefois, avec tout cela, mon problème de réintégration de branche n’est pas résolu. Considérant que j’ai réintégré manuellement le contenu de ma branche, il faut soumettre ces changements à l’historique public.
Pour y arriver, il faut forcer un push de l’historique de développement de la branche master afin qu’elle pointe sur le plus récent commit de l’historique. Ceci se fait en deux étapes :
Vous devinerez que l’image choisie en préambule est drôlement appropriée pour cette opération en particulier. Une fois cela réalisé, le tour est joué et vous pouvez aller prendre un café!
French Coding 