{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 不流泪的眼 的问题《When do you use git rebase instead of git merge?》','https://www.manongdao.com/q-1706.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
When is it recommended to use git rebase vs. git merge?
Do I still need to merge after a successful rebase?
相关问题
- Why does recursive submodule update from github fa
- Extended message for commit via Visual Studio Code
- Emacs shell: save commit message
- Can I organize Git submodules in a flat hierarchy?
- Upload file > 25 MB on Github
相关文章
- 请教Git如何克隆本地库?
- What is the tortoisehg gui equivalent of doing “hg
- How to use Mercurial from Visual Studio 2010?
- GitHub:Enterprise post-receive hook
- Git Clone Fails: Server Certificate Verification F
- SSIS solution on GIT?
- Is it possible to do a “destroy history” in TFS?
- Is there a version control system abstraction for
Short Version
So when do you use either one?
Merge
Rebase
To complement my own answer mentioned by TSamper,
a rebase is quite often a good idea to do before a merge, because the idea is that you integrate in your branch
Ythe work of the branchBupon which you will merge.But again, before merging, you resolve any conflict in your branch (i.e.: "rebase", as in "replay my work in my branch starting from a recent point from the branch
B)If done correctly, the subsequent merge from your branch to branch
Bcan be fast-forward.a merge impact directly the destination branch
B, which means the merges better be trivial, otherwise that branchBcan be long to get back to a stable state (time for you solve all the conflicts)In the case that I describe, I rebase
Bonto my branch, just to have the opportunity to replay my work from a more recent point fromB, but while staying into my branch.In this case, a merge is still needed to bring my "replayed" work onto
B.The other scenario (described in Git Ready for instance), is to bring your work directly in
Bthrough a rebase (which does conserve all your nice commits, or even give you the opportunity to re-order them through an interactive rebase).In that case (where you rebase while being in the B branch), you are right: no further merge is needed:
A git tree at default when we have not merged nor rebased
we get by rebasing:
That second scenario is all about: how do I get new-feature back into master.
My point, by describing the first rebase scenario, is to remind everyone that a rebase can also be used as a preliminary step to that (that being "get new-feature back into master").
You can use rebase to first bring master "in" the new-feature branch: the rebase will replay new-feature commits from the
HEAD master, but still in the new-feature branch, effectively moving your branch starting point from an old master commit toHEAD-master.That allows you to resolve any conflicts in your branch (meaning, in isolation, while allowing master to continue to evolve in parallel if your conflict resolution stage takes too long).
Then you can switch to master and merge
new-feature(or rebasenew-featureontomasterif you want to preserve commits done in yournew-featurebranch).So:
master.Some practical examples, somewhat connected to large scale development where gerrit is used for review and delivery integration.
I merge when i uplift my feature branch to a fresh remote master. This gives minimal uplift work and it's easy to follow the history of the feature development in for example gitk.
I merge when I prepare a delivery commit.
I rebase when my delivery commit fails integration for whatever reason and I need to update it towards a fresh remote master.
Merge means: Create a single new commit that merges my changes into the destination.
Rebase means: Create a whole new series of commits, using my current set of commits as hints. In other words, calculate what my changes would have looked like if I had started making them from the point I'm rebasing on to. After the rebase, therefore, you might need to re-test your changes and during the rebase, you would possibly have a few conflicts.
Given this, why would you rebase? Just to keep the development history clear. Let's say you're working on feature X and when you're done, you merge your changes in. The destination will now have a single commit that would say something along the lines of "Added feature X". Now, instead of merging, if you rebased and then merged, the destination development history would contain all the individual commits in a single logical progression. This makes reviewing changes later on much easier. Imagine how hard you'd find it to review the development history if 50 developers were merging various features all the time.
That said, if you have already pushed the branch you're working on upstream, you should not rebase, but merge instead. For branches that have not been pushed upstream, rebase, test and merge.
Another time you might want to rebase is when you want to get rid of commits from your branch before pushing upstream. For example: Commits that introduce some debugging code early on and other commits further on that clean that code up. The only way to do this is by performing an interactive rebase:
git rebase -i <branch/commit/tag>UPDATE: You also want to use rebase when you're using Git to interface to a version control system that doesn't support non-linear history (subversion for example). When using the git-svn bridge, it is very important that the changes you merge back into subversion are a sequential list of changes on top of the most recent changes in trunk. There are only two ways to do that: (1) Manually re-create the changes and (2) Using the rebase command, which is a lot faster.
UPDATE2 : One additional way to think of a rebase is that it enables a sort of mapping from your development style to the style accepted in the repository you're committing to. Let's say you like to commit in small, tiny chunks. You have one commit to fix a typo, one commit to get rid of unused code and so on. By the time you've finished what you need to do, you have a long series of commits. Now let's say the repository you're committing to encourages large commits, so for the work you're doing, one would expect one or maybe two commits. How do you take your string of commits and compress them to what is expected? You would use an interactive rebase and squash your tiny commits into fewer larger chunks. The same is true if the reverse was needed - if your style was a few large commits, but the repo demanded long strings of small commits. You would use a rebase to do that as well. If you had merged instead, you have now grafted your commit style onto the main repository. If there are a lot of developers, you can imagine how hard it would be to follow a history with several different commit styles after some time.
UPDATE3:
Does one still need to merge after a successful rebase?Yes, you do. The reason is that a rebase essentially involves a "shifting" of commits. As I've said above, these commits are calculated, but if you had 14 commits from the point of branching, then assuming nothing goes wrong with your rebase, you will be 14 commits ahead (of the point you're rebasing onto) after the rebase is done. You had a branch before a rebase. You will have a branch of the same length after. You still need to merge before you publish your changes. In other words, rebase as many times as you want (again, only if you have not pushed your changes upstream). Merge only after you rebase.This answer is widely oriented around Git Flow. The tables have been generated with the nice ASCII Table Generator, and the history trees with this wonderful command (aliased as
git lg):Tables are in reverse chronological order to be more consistent with the history trees. See also the difference between
git mergeandgit merge --no-fffirst (you usually want to usegit merge --no-ffas it makes your history look closer to the reality):git mergeCommands:
Result:
git merge --no-ffCommands:
Result:
git mergevsgit rebaseFirst point: always merge features into develop, never rebase develop from features. This is a consequence of the Golden Rule of Rebasing:
In other words:
I would personally add: unless it's a feature branch AND you and your team are aware of the consequences.
So the question of
git mergevsgit rebaseapplies almost only to the feature branches (in the following examples,--no-ffhas always been used when merging). Note that since I'm not sure there's one better solution (a debate exists), I'll only provide how both commands behave. In my case, I prefer usinggit rebaseas it produces a nicer history tree :)Between feature branches
git mergeCommands:
Result:
git rebaseCommands:
Result:
From
developto a feature branchgit mergeCommands:
Result:
git rebaseCommands:
Result:
Side notes
git cherry-pickWhen you just need one specific commit,
git cherry-pickis a nice solution (the-xoption appends a line that says "(cherry picked from commit...)" to the original commit message body, so it's usually a good idea to use it -git log <commit_sha1>to see it):Commands:
Result:
git pull --rebaseNot sure I can explain it better than Derek Gourlay... Basically, use
git pull --rebaseinstead ofgit pull:) What's missing in the article though, is that you can enable it by default:git rerereAgain, nicely explained here. But put simple, if you enable it, you won't have to resolve the same conflict multiple times anymore.
Git rebase is used to make the branching paths in history cleaner and repository structure linear.
It is also used to keep the branches created by you private, as after rebasing and pushing the changes to server, if you delete your branch, there will be no evidence of branch you have worked upon. So your branch is now your local concern.
After doing rebase we also get rid of an extra commit which we used to see if we do normal merge.
And yes one still needs to do merge after a successful rebase as rebase command just puts your work on top of the branch you mentioned during rebase say master and makes the first commit of your branch as a direct descendant of the master branch. This means we can now do a fast forward merge to bring changes from this branch to master branch.