Le rebase est un outil très puissant pour les branches non publiées. Il te permet de garder un historique propre quand tu mets à jour tes branches locales. Avec bazaar, sans le plugin rebase, tu ne comprends plus rien à ton historique après 10 merges alors que tu as juste mis à jour ta branche contre sa branche d'origine.
Après tu as le rebase interactif, qui n'existe pas dans bazaar. Il te permet entre autre d'avoir des "checkpoint" faciles au cours du dev, d'éviter de tout mélanger dans des gros commits dégueux, ou de sortir des patch sets propres quand tu bosses upstream avec soumissions de patch ou de branches. Tu as des outils de patch managements au dessus de DCVS mais pour la plupart des usages ce que fourni git est suffisant. Bazaar a réussi à me resigner à pousser des commits dégueux par ce que ca n'a pas de sens de perdre 1h pour des choses simples :(
Après pour le merge il faut faire attention car git et bazaar ont deux approches différentes. Bazaar ne fait jamais de "fast-forward" c'est à dire qu'il créé toujours un commit de merge, git lui laisse le choix et par défaut linéarise l'historique quand c'est possible. Ces deux opérations n'ont pas la même sémantique et il est de bon ton de bien spécifier le no-ff à git selon l'opération que l'on fait.
D'une manière générale A successful Git branching model est assez intéressant comme point réflexion initial. Après pour ce qui est local, chacun fait un peu comme il veut. Je suis certain que beaucoup de choses ont été écrites à ce sujet.
[^] # Re: Merge ou rebase ?
Posté par ckyl . En réponse à la dépêche Sortie de Gnu Bazaar 2.6.0. Évalué à 4.
Mix des deux.
Le rebase est un outil très puissant pour les branches non publiées. Il te permet de garder un historique propre quand tu mets à jour tes branches locales. Avec bazaar, sans le plugin rebase, tu ne comprends plus rien à ton historique après 10 merges alors que tu as juste mis à jour ta branche contre sa branche d'origine.
Après tu as le rebase interactif, qui n'existe pas dans bazaar. Il te permet entre autre d'avoir des "checkpoint" faciles au cours du dev, d'éviter de tout mélanger dans des gros commits dégueux, ou de sortir des patch sets propres quand tu bosses upstream avec soumissions de patch ou de branches. Tu as des outils de patch managements au dessus de DCVS mais pour la plupart des usages ce que fourni git est suffisant. Bazaar a réussi à me resigner à pousser des commits dégueux par ce que ca n'a pas de sens de perdre 1h pour des choses simples :(
Après pour le merge il faut faire attention car git et bazaar ont deux approches différentes. Bazaar ne fait jamais de "fast-forward" c'est à dire qu'il créé toujours un commit de merge, git lui laisse le choix et par défaut linéarise l'historique quand c'est possible. Ces deux opérations n'ont pas la même sémantique et il est de bon ton de bien spécifier le
no-ffà git selon l'opération que l'on fait.D'une manière générale A successful Git branching model est assez intéressant comme point réflexion initial. Après pour ce qui est local, chacun fait un peu comme il veut. Je suis certain que beaucoup de choses ont été écrites à ce sujet.