Git has won the race for the most popular version control system. 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.

Although other version control systems also offer some form of branching, Git’s concept and implementation are just stunning. It has made working with branches so quick and easy that many developers have adopted the concept for their daily work. //

Unlike their short-lived colleagues, long-running branches typically remain in a project during its complete lifetime. These branches are not tied to specific features or topics. Instead, they represent states or stages in a project:

• the typical “main” branch for the project’s mainline or production code
• often also a “develop” branch where different short-lived branches are integrated
• sometimes also branches like “staging” or “production” that represent certain stages or environments

Along with this distinction between short-lived and long-running branches, there’s also often a golden rule: never directly commit on a long-running branch; code should only land on these branches through deliberate integration (via merge or rebase).