Merge Branches


make the merge easier.

Since the developer must still take responsibility for the merge, things will go more smoothly if she understands what's really going on.  So let's talk about how merge branches works.  First I need to define a bit of terminology.

For the remainder of this chapter I will be using the words "origin" and "target" to refer to the two branches involved in a merge branches operation.  The origin is the folder which contains the changes.  The target is the folder to which we want those changes to be applied.

Note that my definition of merge branches is a one-way operation.  We apply changes from the origin to the target.  In my example above, $/branch is the origin and $/trunk is the target.  That said, there is nothing which prevents me switching things around and applying changes in the opposite direction, with $/trunk as the origin and $/branch as the target, but that would simply be a separate merge branches operation.

Conceptually, a merge branches operation has four steps:

  1. Developer selects changes in the origin
  2. Source control tool applies some changes automatically to the target
  3. Developer reviews the results and resolves any conflicts 
  4. Commit

Each of these steps is described a bit more in the following sections.

1.  Selecting changes in the origin

When you begin a merge branches operation, you know which changes from the origin you want to be applied over in the target.  Most of the time you want to be very specific about which changes from the origin are to be merged.  This is usually evident in the conversation which preceded the merge:

  • "Dan asked me to merge all the bug fixes from 3.0.5 into the main trunk."
  • "Jeff said we need to merge the fix for bug 7620 from the trunk into the maintenance tree."
  • "Ian's experimental rewrite of feature X is ready to be merged into the trunk."

One way or another, you need to tell your source control tool which changes are involved in the merge.  The interface for this operation can vary significantly depending on which tool you are using.  The screen shot below is the point where the Merge Branches Wizard in Vault is asking me to specify which changes should be merged.  I'm selecting everything back to the last build label:

2.  Applying changes automatically to the target

After selecting the changes to be applied, it's time to try and make those changes happen in the target.  It is important here to mention that merging branches requires us to consider every kind of change, not just the common case of edited files.  We need to deal with renames, moves, deletes, additions, and whatever else the source control tool can handle.

I won't spell out every single case.  Suffice it to say that each operation should be applied to the target in the way that Makes Sense.  This won't succeed in every situation, but when it does, it is usually safe.  Examples:

  • If a file was edited in the origin and a file with the same relative path exists in the target, try to make the same edit to the target file. If this fails, signal a conflict and ask the user what to do.
  • If a file was renamed in the origin, try doing the same rename in the target.  Here again, if the rename isn't possible, signal a conflict and ask the user what to do.  For example, the target file may have been deleted.
  • If a file was added in the origin, add it to the target.  If doing so would cause a name clash, signal

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.