To make a long story short: the main benefit of using branches is that they make software development safe. In the above example, the changes in “FAQ Content” and “New Design #1” don’t get in each other’s way. Branches, in other words, are convenient containers that make developing in multiple, simultaneous contexts safe (and possible in the first place).įeatures and bug fixes are clearly separated from each other, and so are their commits and their code: “Separate” in this regard also means “safe”: if a bug occurs in one context, none of the other contexts are affected by that. Every experiment, every new feature, every bug fix gets its own branch, its own context that is completely separate from all the other development contexts. Let’s imagine the same scenario with branches in mind. When only one context exists that all teammates and all features have to share, commit history looks something like this:Īs the (quite confusing) dotted red lines show, working without branches quickly results in chaos: it becomes hard to understand which commits belong to which feature! In the distant past, where a powerful branching model had not been available, version control was-quite frankly-less useful because a major structural element was not available. A handful of people working together in such a way is enough to bring the whole development process to a halt. Every experiment that a developer has to perform in order to make progress and every bug that is unavoidable in that process will affect all of their teammates. Some may be implementing brand new features, which could introduce bugs in the beginning.
#Git create branch and switch code#
All of them simultaneously editing the same source code files. Let’s dive a little deeper into the details! Why are branches so useful?īranching’s value becomes clear if you think about your workflow without them: imagine that a team of 10 or 20 developers all work in the same “folder,” so to speak. For example, they don’t waste disk space (which a simple file system copy would do) and they are much more capable when it comes to collaborating with other developers in the same project. Of course, they are much more clever than our simple “copy folder” strategy. But there’s an easy way to mitigate these risks: you could simply duplicate the whole project folder! In this copy, you could then make any changes you like, without worrying about breaking something.īranches in Git have the exact same effect and purpose: they provide developers with separate workspaces for their code. In such a situation you would have to be very careful when making changes-because you couldn’t easily undo them and you would risk breaking the current, working version. Just for a moment, let’s pretend that version control and especially its concept of “branches” didn’t exist. when developing a new feature or fixing a problem) will most likely involve a couple of those files. Put simply, a code base is a collection of files. We’ll be looking at the concept of branches in Git from a high-level perspective-with the ultimate goal of better understanding what they are and how they should be used so that you and your team can get the most benefit out of them. What do branches look like under the hood in Git?.How are they used, especially in teams?.In this post, I’d like to explore and explain the what, why, and how of branches: It has made working with branches so quick and easy that many developers have adopted the concept for their daily work. But why exactly is it so popular? The answer, at least in my opinion, is pretty clear: branches! They allow you to keep different versions of your code cleanly separated-ideal when collaborating in a team with other people, but also for yourself when you begin working on a new feature.Īlthough other version control systems also offer some form of branching, Git’s concept and implementation are just stunning. Git has won the race for the most popular version control system.