Branching vs Merging in source control

Can anyone explain in plain English the difference bet开发者_如何学Pythonween the two approaches? A link to a good clearly written tutorial would suffice also.

thank you.

They are not different approaches, but different sides to the same coin.

If you develop using branches, you need to merge them together eventually.

To answer the question:

A branch is a copy of a selected part of your source code, used for specific work (feature, project whatever).

A merge is the act of bringing two branches into sync and (normally) getting rid of one branch in the process.

From wikipedia, Revision control:

Branch

A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other.

Merge

A merge or integration is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows:

• A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users.
• A user tries to check-in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved).
• A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch.
• A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.

Branching is starting a new development line based on the state of the project where you branch from.

Merging is reporting changes from one development line or between development lines to another.

So clearly you need both at different points in time.

Links:

• Branching / Merging primer from microsoft
• A more advanced site about source code management

I don't think you can "oppose" merging vs. branching.

You branch when you want to isolate a development effort, as I explained in "When should you branch?".

The key question to ask, once you have a branch in which you (and other developers) can make evolution to (refactor? enhance? bugfix? ...), is:

"What should you do with the content of that branch?"

In other word, do you leave it alone, or do you re-integrate all its evolutions into another branch. And that is merging.
But merging alone isn't enough. What give merging its purpose is its workflow: from where to where are you merging your code?

Define your workflow, and you will really take advantage of what SCM is about.

In plain English, branching is like "the branch of a tree" where the tree is your software product and the branch is a special part of it that 'extends' from the center-column but has its own features.

In real life you make a branch of your software if you have to support two customers with slightly different whishes. You then have the core-product (A) and the customer-specific-product (B and C) which are basically the core-product with small changes.

Merging is taking this customer-specific branch (B or C), and re-integrating it with your core product (A). This is handy if you implemented a nice feature is branch B, that you'd like to have for everybody, so you merge it into the core product, A.