GNU Info

(emacs)Merging

---

Next: Multi-User Branching Prev: Creating Branches Up: Branches

---

Enter node , (file) or (file)node

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 `vc-merge' command.

`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 C-q
<RET>'.  Version 1.5 is now current.  If locking is used for the file,
type `C-x C-q' 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 conflict".

   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 (Note: 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.

     <<<<<<< name
       USER A'S VERSION
     =======
       USER B'S VERSION
     >>>>>>> 1.11

   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.