2010-06-11 5 views
8

Après avoir travaillé pendant plusieurs semaines avec une demi-douzaine de branches et de fusions différentes, à la fois sur mon ordinateur portable et mon bureau et à la maison, mon histoire est un peu compliquée. Par exemple, je viens de faire une recherche, puis fusionné maître avec origine/maître. Maintenant, quand je fais show-branches git, la sortie ressemble à ceci:comment utiliser git rebase pour nettoyer un historique alambiqué

 
! [login] Changed domain name. 
! [master] Merge remote branch 'origin/master' 
    ! [migrate-1.9] Migrating to 1.9.1 on Heroku 
    ! [rebase-master] Merge remote branch 'origin/master' 
---- 
- - [master] Merge remote branch 'origin/master' 
+ + [master^2] A bit of re-arranging and cleanup. 
- - [master^2^] Merge branch 'rpx-login' 
+ + [master^2^^2] Commented out some debug logging. 
+ + [master^2^^2^] Monkey-patched Rack::Request#ip 
+ + [master^2^^2~2] dump each request to log 
.... 

Je voudrais nettoyer ce avec un rebasage git. J'ai créé une nouvelle branche, rebase-master, à cet effet, et sur cette branche essayé git rebase < commun-ancêtre >. Cependant, je dois résoudre de nombreux conflits, et le résultat final sur la branche rebase-master ne correspond plus à la version correspondante sur master, qui a déjà été testée et fonctionne!

Je pensais avoir trouvé une solution à ce problème mais je ne le trouve plus. Est-ce que quelqu'un sait comment faire ça? Ou ces noms alambiqués vont disparaître quand je commence à supprimer des branches inutiles avec lesquelles j'ai déjà fusionné? Je suis le seul développeur de ce projet, donc personne d'autre ne sera affecté.

+9

;-) Note philosophique: L'histoire devient compliquée. C'est un fait de la vie. Passer à autre chose. –

Répondre

5

Le processus normal, pour repo où vous pouvez forcer pousser une branche (remplaçant l'histoire à distance par un nouveau créé localement par un rebasage), est de faire:

git rebase --interactive 

Mais encore une fois, c'est seulement valable si vous êtes le seul à tirer de vos repos, et même dans ce cas, vous devrez réinitialiser certaines de vos agences locales aux nouvelles applications de suivi à distance qui ont été réécrites.

Depuis la session de rebasage, vous pouvez trimming Git commits and squash history, afin d'obtenir le type d'historique dont vous avez besoin.

+0

Voir aussi http://stackoverflow.com/questions/2719579/howto-add-a-changed-file-to-an-older-not-last-commit-in-git/2719631#2719631 – VonC

+0

umm ... c'est beaucoup valide sans tirer de la télécommande. vous pouvez facilement rebaser -i (ou à peu près à peu près n'importe quoi) branche locale, branche distante, commettre. – xenoterracide

10

La meilleure façon de nettoyer un historique compliqué est de garder l'historique linéaire. Vous faites cela en évitant tout type de fusion autre que l'avance rapide.

Le flux de travail va comme ceci. Au moment de l'intégration de la branche dans le maître, ne la fusionnez pas. Au lieu de cela, rebasez cette branche contre le maître. Cela fera que la branche ne ressemblera plus à une branche, mais simplement à plus de croissance au sommet de l'arbre. Vous résolvez les conflits de fusion lors de la rebase.

$ git fetch origin 
$ git rebase origin/master 

Maintenant, fusionnez la branche en maître. Ce sera une fusion rapide.

$ git checkout master 
$ git merge foobranch 

Et maintenant pousser le travail en amont.

$ git push