How does 'git merge' mess up your commit history?
Consider a team of several developers working on a codebase simultaneously. When getting feature work back in to the main branch, one can either git merge or git rebase .
I have heard from several other developers how using git merge will make your git history funky in comparison to git rebase .
I have also seen this SO question about the difference between merge and rebase.
One SO answer mentions how the advantage of rebase is that a diamond shape is avoided. But what does this really mean in terms of the git logs?
Another SO answer talks about how merging interleaves threads of histories. But isn't it desirable for one's main branch to have all the histories of all the works it contains?
I guess my general question is : what are the differences in how git logs are generated when using merge vs. rebase?
Extra credit: an example of a situation where merging made things very difficult, and rebasing instead would have mitigated this difficulty.
Here a simple example to show the differences in git log --oneline --graph --decorate --all .
Log output after merge
* e8dc85d Merge other branch into master
|
| * 30a040f (other) edited a.txt on other branch
* | 0bc86a0 edited a.txt on master
|/
* b6c1082 added a.txt
Log output after rebase and merge
* 1e42180 Merge another branch into master
|
| * 924fe1e (another) edited b.txt on another branch
|/
* dab33be edited b.txt on master
* 0d64167 added b.txt
Conclusion
There would be really a lot to say (for example in the rebase example, the merge commit could be avoided, but loosing the branch layout in the log).
The main difference for me is that with the rebase, the feature branch is separated vertically from master and other branches merged into master.
Since you are not asking for an opinion, I leave it to you.
链接地址: http://www.djcxy.com/p/45108.html上一篇: 有没有办法让git分支提交更清洁？