rebase master -> devel pour intégrer toutes les nouveautés à ma branche devel
En fait, ça dépend te ton système. Avec git, il déplace vraiment ta branche. À moins d’y avoir mis un tag ou une autre branche, les commits initiaux disparaisse. Avec d’autre ça peut-être un merge de master -> devel, et si tout marche un merge de devel(rebasé) -> master. Ça permet surtout de laisser les problèmes à régler à ceux qui veulent ajouter leur nouvelles feature ou correction. Avant de livrer. Sinon, on peut faire un merge direct, mais si ça casse quelque chose… sur un DVCS c’est pas très grave on peut revenir en arrière (git le fait, les autres je sais pas) mais sur un truc centralisé, s’il y a une boulette, il faut la corriger TRÈS vite alors qu’on veut souvent un master qui reste stable.
Finalement, ce qui est important, c’est ton process de dev, correction, livraison et comment tu l’intègres à ton outil de gestion de conf ainsi qu’à tes éditeurs, logiciels tier de test…
[^] # Re: rebase ou merge
Posté par Anthony Jaguenaud . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 2.
En fait, ça dépend te ton système. Avec git, il déplace vraiment ta branche. À moins d’y avoir mis un tag ou une autre branche, les commits initiaux disparaisse. Avec d’autre ça peut-être un merge de master -> devel, et si tout marche un merge de devel(rebasé) -> master. Ça permet surtout de laisser les problèmes à régler à ceux qui veulent ajouter leur nouvelles feature ou correction. Avant de livrer. Sinon, on peut faire un merge direct, mais si ça casse quelque chose… sur un DVCS c’est pas très grave on peut revenir en arrière (git le fait, les autres je sais pas) mais sur un truc centralisé, s’il y a une boulette, il faut la corriger TRÈS vite alors qu’on veut souvent un master qui reste stable.
Finalement, ce qui est important, c’est ton process de dev, correction, livraison et comment tu l’intègres à ton outil de gestion de conf ainsi qu’à tes éditeurs, logiciels tier de test…