In my two previous articles in this series, we started using Git[1] and learned how to clone, modify, add, and delete[2] Git files. In this third installment, we'll explore Git branching and why and how it is used.
Picture this tree as a Git repository. It has a lot of branches, long and short, stemming from the trunk and stemming from other branches. Let's say the tree's trunk represents a master branch of our repo. I will use master in this article as an alias for "master branch"—i.e., the central or first branch of a repo. To simplify things, let's assume that the master is a tree trunk and the other branches start from it.
Why we need branches in a Git repo
The main reasons for having branches are:- If you are creating a new feature for your project, there's a reasonable chance that adding it could break your working code. This would be very bad for active users of your project. It's better to start with a prototype, which you would want to design roughly in a different branch and see how it works, before you decide whether to add the feature to the repo's
masterfor others to use. - Another, probably more important, reason is Git was made[3] for collaboration. If everyone starts programming on top of your repo's
masterbranch, it will cause a lot of confusion. Everyone has different knowledge and experience (in the programming language and/or the project); some people may write faulty/buggy code or simply the kind of code/feature you may not want in your project. Using branches allows you to verify contributions and select which to add to the project. (This