22.214.171.124 Merging Branches
When you have finished the changes on a certain branch, you will
often want to incorporate them into the file's main line of development
(the trunk). This is not a trivial operation, because development might
also have proceeded on the trunk, so that you must merge the
changes into a file that has already been changed otherwise. VC allows
you to do this (and other things) with the
- C-x v m (vc-merge)
- Merge changes into the work file.
C-x v m (
vc-merge) takes a set of changes and merges it
into the current version of the work file. It firsts asks you in the
minibuffer where the changes should come from. If you just type
<RET>, Emacs merges any changes that were made on the same branch
since you checked the file out (we call this merging the news).
This is the common way to pick up recent changes from the repository,
regardless of whether you have already changed the file yourself.
You can also enter a branch number or a pair of version numbers in
the minibuffer. Then C-x v m finds the changes from that
branch, or the differences between the two versions you specified, and
merges them into the current version of the current file.
As an example, suppose that you have finished a certain feature on
branch 1.3.1. In the meantime, development on the trunk has proceeded
to version 1.5. To merge the changes from the branch to the trunk,
first go to the head version of the trunk, by typing C-u C-x v v
<RET>. Version 1.5 is now current. If locking is used for the file,
type C-x v v to lock version 1.5 so that you can change it. Next,
type C-x v m 1.3.1 <RET>. This takes the entire set of changes on
branch 1.3.1 (relative to version 1.3, where the branch started, up to
the last version on the branch) and merges it into the current version
of the work file. You can now check in the changed file, thus creating
version 1.6 containing the changes from the branch.
It is possible to do further editing after merging the branch, before
the next check-in. But it is usually wiser to check in the merged
version, then lock it and make the further changes. This will keep
a better record of the history of changes.
When you merge changes into a file that has itself been modified, the
changes might overlap. We call this situation a conflict, and
reconciling the conflicting changes is called resolving a
Whenever conflicts occur during merging, VC detects them, tells you
about them in the echo area, and asks whether you want help in merging.
If you say yes, it starts an Ediff session (see Ediff).
If you say no, the conflicting changes are both inserted into the
file, surrounded by conflict markers. The example below shows how
a conflict region looks; the file is called ‘name’ and the current
master file version with user B's changes in it is 1.11.
User A's version
User B's version
Then you can resolve the conflicts by editing the file manually. Or
you can type
M-x vc-resolve-conflicts after visiting the file.
This starts an Ediff session, as described above. Don't forget to
check in the merged version afterwards.