What is Git Branching - Basic Branching and Merging

Zia

2 Followers

Follow

Feb 14, 2024

-

1 sec read

350

0

0

0

Basic Branching and Merging

One of the most remarkable and significant features of the Git version control system is its support for branching. Branching is a functionality that allows users to work on different lines of code at the same time. They can do so parallelly or consecutively. Branching is particularly useful when a user is trying out two different approaches to solve a problem or developing two different features as part of a larger application at the same time. This feature is also very useful during bug fixing when the user wants to solve problems that have been identified in the code. This must be done without harming the already running code. Thus, it is a way to prevent instability from cropping up in the project.

Branching in Git

Branching in Git is significantly better than branching in other version control systems. This is because of the underlying differences in how the branching problem is approached and how a solution is implemented. Most version control systems have tried to solve the problem of supporting different and parallel lines of development. However, the implementation has been radically different in Git. Git's version control system runs on the basis of a series of snapshots, which capture the state and contents of the project at a particular time. When an object in Gitchecksums is computed for all the files belonging to that particular staging operation. staged, When a set of modifications are committed, a commit object is created corresponding to that particular commit operation. This commit object contains comprehensive metadata about that specific commit, such as when it was made, the files that were changed, who made the commit, what message was passed with the commit, and so on. It also contains a pointer to the root tree. This gives the Git version control system the ability to trace the snapshots associated with the committed files. The files themselves are stored as Binary Large Objects (BLOBs).

When a certain branch is under development, It signifies a series of committed operations. Thus, a branch is a pointer to one of these commits, which forms the starting point for the series of chained commits. A new branch can be added easily, as it only has to add a new pointer to one of the commits available in the project's history. Due to this difference in the philosophy of branching, Git's branching mechanisms are very fast and effective, when compared to those of other version control systems.

Merging in Git

Merging in Git is the opposite of branching. Branching refers to the process of creating a new branch and starting a new line of development. On the other hand, merging refers to the process of unifying two separate branches. This is typically done when the purpose for which a branch was created has been accomplished. In such a situation, the code may be ready for use in the main files. Then, merging can be done as a way to integrate the new code with the old and tested code.

Creating a new Branch

Creating a branch in Git is an easy process. It involves only the creation of a new pointer, which gets attached to the commit that the branch is created at. The structure or contents of the repository are not altered in any way. The history of the repository is also not changed. The simplicity of this process makes the branching a distinguishing feature of the Git version control system.

To create a new branch, users can execute the following command at the command prompt: git branch my_new_branch.

Using a Newly Created Branch

The command is written as a git branch that creates a new branch. However, it does not move the development to that branch automatically. Suppose the programmer wishes to use the newly created branch. In that case, the following command can be executed at the command prompt: git checkout 'my_new_branch' After switching to a new branch, project development can be carried on as before, by using the usual commands. As a result of the checkout command, the HEAD pointer shifts to 'my_new_branch' from the original 'master' branch.

Delete, Rename, and Merge Two Branches

Several operations can be carried out on a branch that makes project development convenient in Git.

1. Deleting a Branch

Once the purpose of a branch has been fulfilled, the user may want to delete the branch. For example, a branch created to carry out a specific experiment can be deleted after that experiment has ended. If a branch was created to implement a certain feature or to fix a certain bug, it can be deleted after the task has been accomplished. Before deleting a branch, users must integrate its contents with those of the main code base. This is done by merging. If the branch has been successfully merged, there will be no problem deleting it, as users will not be losing any data by doing so.

To delete a branch, users use the 'git branch -d my branch name' command at the command prompt.

However, if a branch has not been merged successfully and the user still wants to delete it, there is a way to force Git to do so. This should, however, be used sparingly and carefully. To forcefully delete a branch, users can use 'git branch -D my_branch_name' at the command prompt. Here, '-D' functions as an instruction to the system to delete the branch, whereas '-D' functions as a forceful instruction, telling the system to delete the branch even if there are unsaved changes on it.

2. Renaming a Branch

To rename a branch, users must only specify the new name of the branch. Users can navigate to the branch where the name has to be changed and then, execute the following command at the command prompt: 'git-branch -m new_branch_name'.

3. Merging Branches

When users want to integrate the code written in a new branch into an old one, the two branches must be merged. More specifically, the branch to which the merge is happening is called the receiving branch. The branch which is being merged is called the merging branch. After a successful merge, the merging branch will be deleted and the receiving branch will have the entire integrated code for the project. Before the user merges a branch, they must make sure that the HEAD pointer points to the receiving branch. This can be done by using the checkout command. Users can then use the 'git merge merging_branch' command at the command prompt to finish the merge.

Basic Merging to Master Branch

Merging consists of integrating the code present in a branch with that present in another branch. In this section, the most common instance of merging is discussed, which is merging with the branch known as the master branch. The master branch is that branch of the project repository which controls the entire project flow. This is the main branch and is often named master because it is the default name. When a certain bug is fixed or a feature is implemented, or an experiment is ended, the contents of any other branch may be merged into the master branch.

How Merging Works?

Users are aware by now that each branch consists of a series of commits. Merging is a process by which the contents of two branches are integrated. Merging helps users achieve collaboration. When two branches are to be merged, the Git version control system looks for the latest common base commit that the two branches share. After this, a new merge commit is created, which contains the integrated code from that point onwards. The receiving branch is then pointed toward the new merge commit. Suppose two developers, Jack and Pam, are working on a project simultaneously on different branches. They might be working on developing the same feature. If Pam succeeds in building half of the feature properly and Jack succeeds in building the other half, the project's main files will have to contain both their work. Thus, Jack and Pam will both have to merge their work with the main file.

Merge Conflicts

Sometimes, a situation might arise in which Git is unable to merge two branches, due to differences. versions of the same code being present in them. If the merging branch contains only additions to the receiving branch, no merging conflict will arise. However, in most realistic situations, there will be conflicts. For example, consider that the branches of two developers, Jack and Pam, are to be merged. with the main project file. If these branches contain changes to the same part of the file, merge conflicts will arise, because the system will not know whose changes to accept. These conflicts must be handled manually by the user and Git will notify this as the output of the merge command. Until the merge conflicts have been solved, the merge cannot proceed successfully. It will then be necessary for some changes to be made in one of the branches being merged, before merging. These changes will be recorded by Git.