contre rebasage

Question

cueillette de cerises

Ce qui suit est un scénario je fais face couramment:

Vous avez un ensemble de commits sur master ou design, que je veux mettre sur le dessus de la branche production.

J'ai tendance à créer une nouvelle branche à la base comme production écrémer le ces commits sur elle et la fusion à production

Puis, quand je fusionne master à la production, je fais face à des conflits de fusion parce que même quand les changements sont même, mais sont enregistrés comme un engagement différent en raison de cerise-pick.

J'ai trouvé quelques solutions de contournement pour faire face à cela, qui sont toutes laborieuses et peuvent être qualifiées de "hacks". Altho 'Je n'ai pas trop rebasé, je crois que cela crée aussi un nouveau hash de commit. Dois-je utiliser rebasing où je suis cherrypicking. Quels autres avantages cela at-il sur cela.

Answer 1

Vous devriez faire une rebase --interactive votre branche de conception sur le dessus de la production, où:

• vous pouvez modifier l'ordre des commits, en commençant par ceux dont vous avez besoin dans la production
• vous pouvez fusionner la production au dernier validation de la conception que vous souhaitez intégrer (avance rapide)

 
    -x--x--x1--x--x2 (design) 
     \ 
     p--p (production) 

Avec x1 et x2 besoin d'être inclus dans la production:

git checkout design 
git rebase --interactive production 

-x 
    \ 
    p--p (production) 
     \ 
     x1'-x2'--x'--x' (design) 

Puis:

git checkout production 
git merge x2' 
-x 
    \ 
    p--p--x1'--x2' (production) 
       \ 
       x'--x' (design) 

qui vous permet:

• pour valider la conception actuelle engage contre les commits de production (durung rebasage)
• réordonner la conception engage
• inclure les premiers en production
• permet aux fusions ultérieures de la conception à la production d'être rapide.

---

Lakshman Prasad ajoute:

Je pousse les changements à la fin de la journée la plupart du temps. Cela n'aide pas vraiment beaucoup.Comment votre changement de réponse pour la branche principale poussé

Je ferais la même chose, mais avec une branche privée créée juste pour l'opération:

git checkout master 
git checkout -b master-private 

 
    -x--x--x1--x--x2 (master, master-private) 
     \ 
     p--p (production) 

, le rebasage, cette fois-ci avec la branche privée (c'est-à-dire une branche que vous ne pousserez jamais).

git rebase --interactive production 

-x--x--x1--x--x2 (master) 
    \ 
    p--p (production) 
     \ 
     x1'-x2'--x'--x' (master-private) 

Puis:

git checkout production 
git merge x2' 

-x--x--x1--x--x2 (master) 
    \ 
    p--p--x1'--x2' (production) 
       \ 
       x'--x' (master-private) 

master ne bénéficieront pas de l'engager réordonnancement (avec un ordre plus logique), mais au moins vous pouvez pousser master chaque fois que vous voulez.

Et production peut toujours inclure exactement ce dont il a besoin.
Si commits ultérieures master ont le même problème (certains doivent être inclus pour production, autre sera plus tard), je:

• supprimer master-private (nous ne nous soucions pas vraiment les x », copie x engage de maître)
• faire une branche master-private sur le dessus du maître
• refaire le rebase --interactive, avec une tactique de résolution de conflit brut (sauf pour les premiers commits de cette branche master-private, étant donné que ceux-là doivent être intégrés dans la branche production)

 
    -x--x--x1--x--x2--x--x3--x (master) 
     \ 
     p--p--x1'--x2'--x3' (production) 
        |  \ 
        |  x''--x'' (master-private) 
        \ 
        x'..x' (old x' from the first master-private)