Introduction
In this module, we discuss branching and merging with Git. With branching, you create a separate line of development to apply your changes without changing the main line of development. Almost every version control system has some form of branching. Merging is bringing two branches together in one branch. Git always comes with one default branch, the main branch.
With branching, you can create a separate copy of your code to implement your features and changes. In this way, you don't touch the code that is running in a production environment. If there's a critical bug that you need to resolve, you don't risk deploying unfinished code when you or a team member resolves that bug. The bug can be fixed directly on the production code and redeployed in production when resolved. Typically, you also create a separate branch to resolve the bug first. We mentioned that you create a separate copy, but it isn't really a copy. Git works with pointers. Each commit performed in Git gets a unique ID. A branch points to a specific commit in time. If you create a new branch, this branch also points to a specific commit. Every time you change something and commit that change, your branch points to another commit.
With this approach, you can have multiple branches all pointing to another commit, and it's easy to fix something. While branching in most version control systems can be tedious, in Git it's fairly straight-forward, because it's just creating a pointer to a specific commit. Therefore, Git encourages developers to branch and merge multiple times a day. Try to make your features or changes as small as possible and create a branch for each feature. Test the feature and merge back into your main development branch.
Implementing branching and merging changes the way you develop, but it also allows the setup of continuous integration in Azure DevOps.