Branching and tagging are concepts common to almost all version control systems. Branch is a separate line of development that exists independently of another line. It always begins life as a copy of something, and moves on from there, generating its own history. Branches are created mainly for the following purposes: independent development of the current revision with the correction support in the release version, long-term independent work, using of source codes of other developers. All three opportunities are shown in the table. There you can also find a more detailed explanation of the algorithm for each opportunity.

Branch Release	Long, isolated work	Using of codes from 3rd vendors
[ 0] tags branches [ 1] [ 2] [ 3]---)[release, 4]-->[release, 5] | [6] | --------------[7] [ 8] / [ 9](----- [10]--->[release2, 11]--> ... [head]	[ 0] [ 1] [ 2] [ 3]----)[longwork1, 4] | [ 5] [ 6] | | [ 7] [ 8](------/ [ 9] [10]-----[longwork2, 11] | [12] | [13] [14] / [15](------ [head]	[ 0] [ 1]---->[3rdcode, 2] [ 5](-----[ 3]--->[3rdcode_update1, 4] [ 6] | [ 7] | [10](-----[ 8]--->[3rdcode_update2, 9] [11] | [14](-----[12]--->[3rdcode_update3, 10] [15] [head]
Permanent development takes place on the main branch. At the time of version release the main branch is tagged, and a branch is created on the base of this tag. When bug fixing in release version takes place, it is performed on the "release" branch. Before issuing of a new release, fixes from the release branch are merged with the basic codes (to prevent repeating of the same errors). Then everything is repeated.	Permanent development takes place on the main branch. When it is necessary to perform long work, a part of developers goes to the "longwork1" branch. There they make modifications, which are merged with the main branch afterwards. The essence of this work is that it is sometimes necessary to modify, for instance, the system kernel. Moreover, the modifications have no effect on functions etc. Modifications are just special internal changes increasing efficiency and so on. The modification can be extensive enough to require work of several developers, or for one developer it may be better to checkin his work step-by-step to the server in order to secure the source codes.	This situation arises when you use ready source codes of other developers. The very first version of theirs is tagged '3rdcode'. Commonly it is necessary to adapt these codes some way: change titles, maybe add new functions etc. This work is performed on the main branch. Meanwhile the imported source codes can also be modified by their "owners". These modifications are added to the branch '3rdcode', and then are merged with the modifications on the main branch.
The project is developed. At the time of the project release the branch 'release1' is created. The project development is continued. At some moment it becomes necessary to fix bugs in the release version. Get the main branch again. Continue the project development. Point 4 can take place several times. A new release is ready. Merge modifications of the branch "release1" with the main branch. Create the branch "release2". ...	The project is developed. At the moment of taking a decision about long work Get the branch 'longwork1'. The branch "longwork1" is modified while others work with the main branch. At the end of work Merge modifications with the branch "longwork1". ...	The code of other developers is used. Right away the branch '3rdcode' is created. Adaptation on the main branch is performed. At the moment you get the new version from other developers '3rdcode_update1'. merge it with the branch '3rdcode'. Adaptation on the main branch is performed. At the moment you get the next new version from other developers create the tag '3rdcode_update2'. merge it with the branch '3rdcode'. Select modifications performed only between the tags '3rdcode_update1' and '3rdcode_update2'. Adaptation on the main branch is performed. ...

A tag is just a "snapshot" of a project in time. In GIT each commit is a snapshot of the repository file system after each commit, and it can be used as a tag. But people often want to give some human-friendly names to tags, like release-1.0. Tag is a named snapshot, a symbolical connection with the specified commit of a project.

It is generally known that in GIT tags and branches realization is implemented by copying the source code tree to the repository. GIT uses so-called "cheap copies". Instead of making a real copy, the internal link will be created, pointing to a specific tree/commit. As a result branches and tags are very quick to create, and take up almost no extra space in the repository.

You can work with tags and branches in an IDE. GITSCC plug-in includes support for some basic operations, such as tag/branch creation, switching and merging. You can also use other GIT tools to perform any advanced operations, but keep in mind that plug-in automatically adjusts some auxiliary GIT properties and in this case you have to correct them manually.