Branches and branching strategies
Branches in Git allow you to diverge from the main line of development and work independently without affecting the main codebase. This is like having your own parallel universe where you can experiment, develop new features, or fix bugs without interfering with the stable version of your project.
Let's start by listing all the branches in your repository. You can do that using the git branch command with no arguments.
Use the git branch command to list all branches.
If you didn't do any undercover experiments on your own, you should see only one branch, which is your default branch main. This is the branch that is always created when you initialize a new repository.
Branches are simply pointers to commits. There's another pointer called HEAD, that points to the latest commit on the current branch. When you make a new commit, the branch pointer advances to that commit, as does the HEAD. When you switch branches, the HEAD pointer moves to the latest commit of the new branch.
Now, let's move on to branching strategies, which are part of git workflow. A branching strategy is a set of rules and guidelines for creating, naming, and managing branches in a project. In a large project with multiple developers, there may be hundreds of branches, and a good branching strategy can help keep things organized and manageable. Here are some common git workflows:
-
Centralized Workflow. All developers work on a single branch, typically the
mainbranch. This workflow is the simplest, but you don't get the benefits of feature isolation and parallel development. Most often, it is used by teams who used to work with the old centralized version control systems. -
Feature Branch Workflow. Each new feature is developed on its own branch, then merged into the
mainbranch when complete. This is the most common workflow for teams using Git. This workflow allows developers to work on multiple features simultaneously without interfering with each other. -
Gitflow Workflow. A more structured approach with long-running branches (
main&develop), and short-lived branches (feature,release, andhotfix). This workflow is suitable for larger projects with multiple releases and parallel development efforts. It provides a clear path for new features and bug fixes from development to production. However, it is quite complex and may be overkill for smaller projects. -
Forking Workflow. Each developer has their own fork (copy) of the repository and submits pull requests to the main repository, where the changes are reviewed and merged by someone who has write access to the main repository. This workflow is common in open-source projects where contributors don't have write access to the main repository. It allows for a high degree of isolation and control over contributions.
Hi! I'm Alex, creator of GitByBit.
This page is a part of the interactive course about Git version control.
It's a one-of-a-kind course that is integrated into the VS Code code editor. Learning directly in VS Code lets you operate Git exactly as you would in real life, doing real jobs, writing real code.
In addition, the course has access to your actual terminal, so it can point out mistakes, suggest workarounds, etc.
The course is FREE, there are no Ads or other bullshit. There are optional premium add-ons you can purchase, mainly to support my work (regrettably, I have to eat every day), but that's totally up to you.