Dans un monde idéal c'est super. Franchement. Avant on avait un historique, comment dire... horrible, des merges dans tous les sens, etc.
C'est à mon avis là que se situe le problème : pas un problème technique, mais une problème de compréhension. Git force certains processus, c'est sûr, mais il en facilite d'autres. En particulier, ses capacités de fusion de modifications favorisent les processus qui utilisent des branches multiples et des fusions.
Donc, ici, ma question est : pourquoi le fait d'avoir plusieurs branches, et des fusions régulières entre ces branches, te semble-t-il problématique ? Parmi les projets logiciels les plus compliqués en terme de taille et d'organisation humaine, il y a le noyau Linux, qui est maintenu sous la forme de tas de branches et de fusions, et visiblement ça marche, donc je ne pense pas que ce soit un problème en tant que tel.
À mon avis, il serait plus utile de cesser de faire la grimace devant un historique qui présente des branches multiples, et considérer cela comme un fait sans conséquences.
En particulier, dans la vraie vie :
pas de branches de prod, maintenance, etc
Il n'y a pas vraiment de moyen d'échapper à l'utilisation de branches de maintenances. C'est bête, mais quand tu as sorti Logiciel v2.3, et que tu développes sur les v2.4, si quelqu'un signale un bug qui doit être corrigé sur la v2.3, on ne peut pas faire cette correction sur la seule branche de travail de la v2.4, et il faut donc introduire une branche de maintenance. Et pour que cette correction soit appliquée aussi à la v2.4, Git fournit une solution : créer une branche de correction, basée sur le dernier commit commun à la v2.3 et à la v2.4, y effectuer cette correction, puis la fusionner dans les branches de la v2.3 et de la v2.4, comme ça :
# Pourquoi ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 9.
C'est à mon avis là que se situe le problème : pas un problème technique, mais une problème de compréhension. Git force certains processus, c'est sûr, mais il en facilite d'autres. En particulier, ses capacités de fusion de modifications favorisent les processus qui utilisent des branches multiples et des fusions.
Donc, ici, ma question est : pourquoi le fait d'avoir plusieurs branches, et des fusions régulières entre ces branches, te semble-t-il problématique ? Parmi les projets logiciels les plus compliqués en terme de taille et d'organisation humaine, il y a le noyau Linux, qui est maintenu sous la forme de tas de branches et de fusions, et visiblement ça marche, donc je ne pense pas que ce soit un problème en tant que tel.
À mon avis, il serait plus utile de cesser de faire la grimace devant un historique qui présente des branches multiples, et considérer cela comme un fait sans conséquences.
En particulier, dans la vraie vie :
Il n'y a pas vraiment de moyen d'échapper à l'utilisation de branches de maintenances. C'est bête, mais quand tu as sorti Logiciel v2.3, et que tu développes sur les v2.4, si quelqu'un signale un bug qui doit être corrigé sur la v2.3, on ne peut pas faire cette correction sur la seule branche de travail de la v2.4, et il faut donc introduire une branche de maintenance. Et pour que cette correction soit appliquée aussi à la v2.4, Git fournit une solution : créer une branche de correction, basée sur le dernier commit commun à la v2.3 et à la v2.4, y effectuer cette correction, puis la fusionner dans les branches de la v2.3 et de la v2.4, comme ça :
À mon avis, oui.