À 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.
Ça c'est vrai, à une condition : que tu ne cherches jamais à relire ton historique. Un gestionnaire de source c'est un outil au quotidien pour partager le boulot mais c'est aussi un historique qui se doit d'être clair et compréhensible. Il m'est déjà arrivé de passer 1,5 jour uniquement à chercher le commit ayant entrainé une régression. L'historique contenait tellement de merges dans tous les sens que c'en était illisible et qu'un bisect était horrible.
Et malheureusement revenir dans l'historique est une pratique relativement fréquente, surtout dans notre cas particulier qui est de ne pas pouvoir valider à 100% un code sans "prendre la voiture un jour de beau temps, faire quelques dizaines de bornes, tester sur du matériel réel, rentrer". Ce qui introduit de la latence. Et comme il y a latence on bosse déjà sur la suite et, si le point en test n'est pas passé, alors on reviens dessus pour le corriger.
Maintenant s'il y a moyen d'avoir un historique lisible avec des branches à tout vas, je veux bien ;-)
Il n'y a pas vraiment de moyen d'échapper à l'utilisation de branches de maintenances. [...]
Attention, je ne dis pas qu'il n'y en aura jamais. Juste que là maintenant il n'y en a pas. master est notre branche stable et en quelque sorte il n'y a pas de maintenance à faire puisqu'on est en plein dans une phase de dev et non d'exploitation.
Et même sans ça, en vrai si il est possible de se passer de ces branches, mais c'est des choix différents qui sont d'avoir quelque chose qui s'approche plus de la "rolling release".
[^] # Re: Pourquoi ?
Posté par CrEv (site web personnel) . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
Oui et non. Oui en apparence, dans le détail il y a des règles qui sont entre autre "ne te fusionne pas avec l'upstream n'importe quand / comment" (http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html)
Ça c'est vrai, à une condition : que tu ne cherches jamais à relire ton historique. Un gestionnaire de source c'est un outil au quotidien pour partager le boulot mais c'est aussi un historique qui se doit d'être clair et compréhensible. Il m'est déjà arrivé de passer 1,5 jour uniquement à chercher le commit ayant entrainé une régression. L'historique contenait tellement de merges dans tous les sens que c'en était illisible et qu'un bisect était horrible.
Et malheureusement revenir dans l'historique est une pratique relativement fréquente, surtout dans notre cas particulier qui est de ne pas pouvoir valider à 100% un code sans "prendre la voiture un jour de beau temps, faire quelques dizaines de bornes, tester sur du matériel réel, rentrer". Ce qui introduit de la latence. Et comme il y a latence on bosse déjà sur la suite et, si le point en test n'est pas passé, alors on reviens dessus pour le corriger.
Maintenant s'il y a moyen d'avoir un historique lisible avec des branches à tout vas, je veux bien ;-)
Attention, je ne dis pas qu'il n'y en aura jamais. Juste que là maintenant il n'y en a pas.
masterest notre branche stable et en quelque sorte il n'y a pas de maintenance à faire puisqu'on est en plein dans une phase de dev et non d'exploitation.Et même sans ça, en vrai si il est possible de se passer de ces branches, mais c'est des choix différents qui sont d'avoir quelque chose qui s'approche plus de la "rolling release".