StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>To complement <a href="https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions">my own answer</a> mentioned <a href="https://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804119#804119">by TSamper</a>, </p> <ul> <li><p>a rebase is quite often a good idea to do before a merge, because the idea is that you integrate in your branch <code>Y</code> the work of the branch <code>B</code> upon which you will merge.<br> But again, before merging, you resolve any conflict in <em>your</em> branch (i.e.: "rebase", as in "replay my work in my branch starting from a recent point from the branch <code>B</code>)<br> If done correctly, the subsequent merge from your branch to branch <code>B</code> can be fast-forward.</p></li> <li><p>a merge impact directly the destination branch <code>B</code>, which means the merges better be trivial, otherwise that branch <code>B</code> can be long to get back to a stable state (time for you solve all the conflicts)</p></li> </ul> <hr> <blockquote> <p>the point of merging after a rebase? </p> </blockquote> <p>In the case that I describe, I rebase <code>B</code> onto my branch, just to have the opportunity to replay my work from a more recent point from <code>B</code>, but while staying into my branch.<br> In this case, a merge is still needed to bring my "replayed" work onto <code>B</code>.</p> <p>The other scenario (<a href="http://www.gitready.com/intermediate/2009/01/31/intro-to-rebase.html" rel="noreferrer">described in Git Ready</a> for instance), is to bring your work directly in <code>B</code> through a rebase (which does conserve all your nice commits, or even give you the opportunity to re-order them through an interactive rebase).<br> In that case (where you rebase while being in the B branch), you are right: no further merge is needed:</p> <p><strong>A git tree at default when we have not merged nor rebased</strong></p> <p><img src="https://i.stack.imgur.com/7vsGZ.png" alt="rebase1"> </p> <p><strong>we get by rebasing:</strong></p> <p><img src="https://i.stack.imgur.com/yCxOO.png" alt="rebase3"></p> <p>That second scenario is all about: how do I get new-feature back into master.</p> <p>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").<br> You can use rebase to first bring master "in" the new-feature branch: the rebase will replay new-feature commits from the <code>HEAD master</code>, but still in the new-feature branch, effectively moving your branch starting point from an old master commit to <code>HEAD-master</code>.<br> That allows you to resolve any conflicts in <em>your</em> branch (meaning, in isolation, while allowing master to continue to evolve in parallel if your conflict resolution stage takes too long).<br> Then you can switch to master and merge <code>new-feature</code> (or rebase <code>new-feature</code> onto <code>master</code> if you want to preserve commits done in your <code>new-feature</code> branch).</p> <p>So: </p> <ul> <li>"rebase vs. merge" can be viewed as two ways to import a work on, say, <code>master</code>. </li> <li>But "rebase then merge" can be a valid workflow to first resolve conflict in isolation, then bring back your work.</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload