Given the appropriate settings for folders, files, and change requests, you can branch these items in a child view—that is, you can separate these items from the corresponding items in the parent view.
Branching a folder does not branch its contents (child folders nor items.)
After an item branches, it receives a new revision number. For example, if a file's revision number (in dot notation) 1.13 before the file branches, it becomes 1.13.1.0 after branching. The next change to the file in the parent view will receive the revision number 1.14. The next change in the child becomes 1.13.1.1.
Below are the basic facts about branching behavior:
Suppose you are working on a product and a customer requests a special edition of the product with a few special features tailored specifically for that customer. To separate the current product's items from those for the special request, a branching view is created.
When items are branched, they are derived from other items that become their ancestors. Items may have several completely different revision histories with common ancestries. In the case of a text file, for example, the branched item can later be merged with the file from which it originated. For example, the development of a product for a new operating system may start with the existing files for the first operating system as its base.
Whether or not a folder, file, or change request has the ability to branch depends on its history. If you do not know the complete history, you should not assume that you know its behavior. For example,
The “branch on change” behavior of a shared item is specific to the folder it is in and the "branch on change" check box is selected by default for the shared file.