This document provides instructions for merging feature branches, resolving conflicts during merging, and rebasing branches. It explains how to merge two feature branches into the master branch, how to identify and resolve conflicts using merge tools, and how to undo a merge or rebase using reset. It also demonstrates rebasing a feature branch instead of merging and resolving conflicts that arise during rebasing.

1. Merge, Rebase and how to resolve
Conflicts
In this exercise you will learn how to combine the work done in different branches and how
to resolve the conflicts which can occur during that process.
Preparation
Follow exercise 2, “Develop a feature/bug fix” to create a commit on a feature branch based
on the remote tracking branch origin/master.
Create a Conflicting commit
You may skip this step if you have already created conflicting changes in the previous
exercises. This is the case if you touched exactly the same line of the same file in different
feature branches. If this is not the case please do the following:
● Create a new local branch based on the remote tracking branch “origin/master”
● Create the new branch from the History View :
○ Select the project, then click Show In > History
○ Click “Create Branch...” on the commit where origin/master points to
● Do a different change in the same class on the same line as in the other branch (e.g.
you may add a class MultiplyOperation and add a corresponding line to method
setupDefaultOperations in class Calculator) and commit this change.

2. Merge the feature branches
Now you would like to have both new features in the master branch. One possibility to
achieve that is to merge the branches into the master branch, one after the other. Later in
this exercise you will learn another way, rebasing.
Trigger the first merge from the history view
● Check out the branch master where you want to have the merged state, i.e. where
the merge commit will be created, either by double clicking in the Repositories View,
or by selecting Checkout in the History View, or by using Team > Switch to > master,
or using the Checkout button in the Git tool bar.
● In the History View, select Merge in the context menu of the addDivide branch.
This will merge the content of the addDivde branch into the master branch. Since
there was no work done on the master branch and addDivide points to a successor
commit of the commit in master there is not much to do.
● Git simply forwards the master branch to the same commit as the addDivide
branch.
● Inspect the result in the history view.

3. Merge the second branch
● In the History View, select Merge in the context menu of the branch which contains
the conflicting commit. This will merge the content of this branch into the master
branch. This time the merge operation ends with conflicts.
Resolving merge conflicts
If a merge generates conflicts the repository is in a special state. The conflicts have to be
resolved until normal work can go on.
You can find the conflicting files by the conflict decorator in the package explorer::
If there are many conflicts it’s easier to find them in the Git Staging View:
● If you open the conflicting file in an editor you will find the conflict markers there. You
can directly edit the file here.

4. ● You may use the Merge tool to resolve the conflicts: Select Merge Tool on the
conflicting file in the Staging View or “Team > Merge Tool” in the package explorer.
● By default the merge tool will show the two versions being merged, you can also
choose to let git pre-merge the file content by setting “Preferences > Team > Git
> Merge Tool Content” to “Workspace (pre-merged by Git)”. In this case conflict
markers are shown in the left pane in the file content pre-merged by git
● Click “Copy Current Change from Right to Left”
to take over the current change from right to left

5. ● or edit the left side until you are happy with the change and save the file
● Now stage these modifications in the staging view or click “Team > Add to Index” on
the file. This marks the conflict as resolved and adds the conflict resolution to the git
index to add the conflict resolution to the merge commit in the next step.
● Click “Commit” in the Staging View. Note that git generates a merge commit
message. Leave it as it is, but do not forget the Change-Id-line in the Staging View if
you want to push the change to Gerrit later.
Undo merging with Reset
After you have done a merge as described above assume that you do not want the merge
commit in your branch anymore. You can easily undo the merge with the Reset operation.
(The same can also be done if the merge is not finished but your repository is in state
“Conflicting” or “Merged”).
● Select Reset > Hard on the commit where the branch pointed to before you did the
first merge.

6. Rebase
Now do a rebase of the conflicting commit instead of a merge.
● In the History View, check out one of the feature branches
● In the History View, select Rebase on on the second feature branch (the first one is
checked out):
● The rebase stops because of the conflict and shows the following dialog:

7. ● Click Ok to start the merge tool.
● Again use the Merge tool to resolve the conflicts. Again as shown above for merge
you can adjust setting “Merge tool content” to let git pre-merge the file content in the
preferences.
Edit the left side until you are happy with the change and save

8. ● Now open the Git Staging View
● Move the conflicting file to the “Staged Changes” area to tell git that the conflict is
resolved. If there are no conflicting files anymore, the “Continue” button gets enable.
Click the “Continue” button. Note: rebase is continued by a different operation
(“Continue”) than merge (“Commit”) since rebase is a multi-step operation which may
raise conflicts multiple times if you you are not only rebasing a single but multiple
commits in one go.

9. ● Now the version graph should look like this: Note that there is a reference
ORIG_HEAD pointing to the commit which was checked out before the rebase
operation. You may revert the rebase operation with reset as described above.
● Now you may want to move the master branch to the rebased commit
○ Check out the master branch
○ Select “Rebase On” on the rebased commit
Copyright © 2014 by C. Halstrick, E. Kempin, S. Lay, S. Zivkov