-
Notifications
You must be signed in to change notification settings - Fork 34
git fast forward
Incorporates changes into the current branch. By default the upstream branch is used, but a different commit can be specified in the arguments.
Assume the following history exists and the current branch is
master:
D---C---B---A origin/master
^
|
master
Then git fast-forward will advance the local master to origin/master:
D---C---B---A origin/master ^ | master
This operation is not always possible; if you’ve made changes and the branches diverged:
D---C---B---A origin/master \ X---Y master
then the fast-forward command will fail.
In those cases you need to either git merge, or git rebase in order to
synchronize the two branches.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOUR MAY CHANGE.
The decision to whether merge or rebase depends on the situation and the project. Traditionally git has prefered merge over rebase, but that creates a new commit, and that’s frowned up on some projects, so you can’t just simply choose to merge blindly.
D---C---B---A origin/master \ X---Y master
The nature of distributed version control systems make this divergence unavoidable; you must decide how to synchronize this divergence.
Should you choose to merge, the two heads (master and origin/master) will be joined together in a new commit:
origin/master
|
v
D---C---B---A---M master
\ /
X---Y---+
This new commit is called a "merge commit" and has two parents (A and Y).
Rebasing on the other hand rewrites the history:
origin/master
|
v
D---C---B---A---X'---Y' master
The commits that diverged (X and Y) are rewritten as if they were created on top of the new base (A). This creates a linear history, which is cleaner, but some people prefer to preserve the original history.
In both cases it’s likely you would have to resolve conflicts, the difference is that in a merge you would have to do it all at once in one commit, while with a rebase you would have to do it on every rewritten commit.