Git Branching: Creating, Switching, and Deleting Branches

Branches are one of the most powerful features in Git, enabling developers to work on different features, bug fixes, or versions of a project simultaneously. Whether you're working on a new feature or fixing a bug, Git allows you to create and manage branches with ease, ensuring that your main codebase stays clean and stable until you're ready to merge your changes.

In this post, we will dive deep into:

• How to create new branches
• How to switch between branches
• How to delete branches
• Best practices for using Git branches

1. What Are Git Branches?

In Git, a branch is essentially a pointer to a specific commit in your project’s history. When you create a new branch, you're creating a new line of development that starts from an existing commit, typically from the main branch (often called main or master).

Branches allow you to work on a different version of your project without affecting the original code. Once you're done making changes, you can merge the branch back into the main branch or discard it if needed.

Why Use Branches?

• Parallel development: Work on different features or bug fixes without interfering with the main project.
• Isolation: Keep incomplete or experimental changes separate from the stable codebase.
• Collaboration: Multiple developers can work on different branches without stepping on each other’s toes.

By default, every Git repository has a main branch (or master in older repositories), which is where the mainline code lives. However, it’s common practice to create branches for new features, bug fixes, or other tasks.

2. Creating Branches in Git

Creating a branch in Git is simple and can be done using the git branch or git checkout command (with modern Git versions, git switch is also used).

2.1 Creating a New Branch

To create a new branch, you use the git branch command followed by the name of the branch you want to create.

Syntax:

git branch <branch-name>

Example:

Let’s say you want to create a new branch to work on a feature called "feature-login".

git branch feature-login

At this point, the branch has been created, but you’re still on your current branch (probably main or master). To start working on the new branch, you’ll need to switch to it.

2.2 Creating and Switching to a Branch in One Step

You can create and switch to a new branch in one step using the git checkout command or the newer git switch command (available in Git 2.23 and later).

Using git checkout:

git checkout -b feature-login

Using git switch:

git switch -c feature-login

Both of these commands create the new branch and immediately switch you to it, allowing you to start making changes right away.

3. Switching Between Branches

Once you have multiple branches in your repository, you can switch between them using git checkout or git switch. Switching between branches allows you to move from one branch to another to work on different tasks.

3.1 Switching with git checkout

To switch to a different branch, use the git checkout command followed by the branch name.

Syntax:

git checkout <branch-name>

Example:

If you want to switch back to the main branch after working on the feature-login branch, run:

git checkout main

After running this command, your working directory will reflect the state of the main branch, and any uncommitted changes you had in the previous branch will stay there (as long as they were committed).

3.2 Switching with git switch

If you’re using a modern version of Git (2.23+), you can use the git switch command, which was introduced to simplify branch switching.

Syntax:

git switch <branch-name>

Example:

git switch main

This command does the same thing as git checkout <branch-name>, but it's a cleaner and more intuitive way to handle branch switching in modern Git workflows.

3.3 Handling Uncommitted Changes When Switching Branches

If you have uncommitted changes in your working directory and you try to switch branches, Git will prevent you from doing so. This is because switching branches with uncommitted changes could lead to conflicts or loss of work.

Example:

git switch main
error: Your local changes to the following files would be overwritten by checkout:
  index.html
Please commit your changes or stash them before you switch branches.

In this case, you can either commit your changes, stash them using git stash, or discard them.

• Committing your changes: Save the changes by committing them.

git commit -m "Work in progress"

• Stashing your changes: Temporarily store the changes without committing them.

git stash

Once your changes are stashed, you can switch branches and later retrieve the stashed changes with:

git stash apply

4. Deleting Branches in Git

When you're done working on a feature or a bug fix, and the changes have been merged back into the main branch, you might want to delete the branch to keep your repository clean.

4.1 Deleting a Local Branch

To delete a local branch, you use the git branch -d command followed by the branch name.

Syntax:

git branch -d <branch-name>

Example:

git branch -d feature-login

This will delete the feature-login branch from your local repository. However, Git will only allow you to delete a branch if it has been fully merged with another branch (e.g., the main branch). If the branch hasn’t been merged, you’ll see an error message.

4.2 Forcing Branch Deletion

If you’re sure you want to delete a branch that hasn’t been merged, you can force the deletion with the -D flag:

git branch -D feature-login

Be cautious when using this option, as you will lose any unmerged changes.

4.3 Deleting Remote Branches

To delete a branch from the remote repository (e.g., on GitHub or GitLab), you’ll use the git push command with the --delete flag.

Syntax:

git push origin --delete <branch-name>

Example:

git push origin --delete feature-login

This command will delete the feature-login branch from the remote repository.

5. Branching Best Practices

When working with Git branches, it's important to follow some best practices to keep your workflow clean and maintainable:

5.1 Use Descriptive Branch Names

Branch names should be descriptive and easy to understand. Instead of naming your branch fix1, use something more descriptive like bugfix-header-overflow. This makes it easier for your teammates (and yourself) to understand what the branch is for.

5.2 Keep Branches Short-Lived

It's a good practice to keep branches short-lived and merge them into the main branch as soon as the feature or bug fix is complete. This reduces the risk of long-lived branches diverging too much from the main codebase, which can lead to complex merge conflicts.

5.3 Always Test Before Merging

Before merging your branch into the main branch, make sure to test your changes thoroughly. This can be done locally or through automated CI/CD pipelines. This ensures that you don’t introduce bugs or break the main branch.

5.4 Keep Your Branches Up-to-Date

Regularly pull changes from the main branch into your working branch to avoid large, difficult merges later. This can be done with:

git pull origin main

or

git merge main

Conclusion

Git’s branching model is incredibly flexible and powerful, allowing you to work on different features, fixes, or versions of a project in isolation. Understanding how to create, switch, and delete branches is essential for effective Git workflows, especially when collaborating with other developers.

Here’s a quick summary of what we’ve covered:

• Creating branches: Use git branch <branch-name> to create a new branch, or use git checkout -b <branch-name> or git switch -c <branch-name> to create and switch to a new branch in one step.
• Switching branches: Use git checkout <branch-name> or git switch <branch-name> to move between branches.
• Deleting branches: Use git branch -d <branch-name> to delete a branch locally and git push origin --delete <branch-name> to remove it from the remote repository.
• Best practices: Follow naming conventions, keep branches short-lived, and test thoroughly before merging.

By mastering these basic branch operations, you’ll be able to manage multiple lines of development with ease and confidence. In the next post, we’ll dive deeper into working with Git branches in collaborative environments, including pull requests and merge strategies!