Git Branches

Edit PagePage History

Introduction

Branches are one of Git's most powerful features, allowing developers to work on multiple features or fixes simultaneously without interfering with each other. This guide explains what branches are, how to use them effectively, and how they fit into your overall Git workflow.

🎥 Video: Git Branches Tutorial (33 mins) - How to work with branches effectively

What are branches? Why do we use them?

A branch in Git is simply a lightweight movable pointer to a commit. The default branch in Git is called main (or master in older repositories). Each time you make a commit, the branch pointer automatically moves forward to point to your latest commit.

Why use branches?

Branches are essential to modern software development for several reasons:

• Isolation: Work on new features without affecting the stable main codebase
• Parallel Development: Multiple developers can work on different features simultaneously
• Experimentation: Try out ideas in a separate branch without commitment
• Organization: Group related changes together
• Code Review: Make it easier to review changes before merging them into the main codebase

💡 Tip: Even if you're working alone, branches help you organize your work and keep your main branch stable.

Creating and Switching Branches

Git provides several commands for working with branches.

Creating a Branch

# Create a new branch
$ git branch feature/login

This creates a new branch called feature/login but doesn't switch to it.

Switching to a Branch

# Switch to an existing branch
$ git checkout feature/login
Switched to branch 'feature/login'

Creating and Switching in One Command

# Create and switch to a new branch
$ git checkout -b feature/payment
Switched to a new branch 'feature/payment'

Listing Branches

# List all branches (* indicates current branch)
$ git branch
  main
  feature/login
* feature/payment

⚠️ Note: When you create a new branch, it starts at your current position (commit). Any new commits you make will be part of this branch until you switch to another one.

Branching Strategies

There are several popular branching strategies used by development teams:

Feature Branching

In this simple approach, each new feature gets its own branch. Once the feature is complete, it's merged back into the main branch.

Gitflow

Gitflow is a more structured branching model with specific branch types:

• main: Production-ready code
• develop: Integration branch for features
• feature/*: New features
• release/*: Preparing for a release
• hotfix/*: Quick fixes to production

💡 Tip: Choose a branching strategy that fits your team size and project needs. Simple projects may only need feature branches, while larger projects benefit from more structure.

Merging Branches

Merging is the process of combining changes from one branch into another. When you've completed work in a feature branch, you'll want to merge it back to your main branch.

Basic Merge Process

# Switch to the receiving branch (usually main)
$ git checkout main

# Merge the feature branch into the current branch
$ git merge feature/login
Updating a1b2c3d..e5f6g7h
Fast-forward
 login.html   | 65 +++++++++++++++++++++++
 login.css    | 42 ++++++++++++++++
 login.js     | 103 +++++++++++++++++++++++++++++++++++++
 3 files changed, 210 insertions(+)

Types of Merges

Git performs different types of merges depending on the situation:

1. Fast-forward merge: If no new commits have been made to the main branch since the feature branch was created, Git simply moves the main pointer forward. This is the simplest kind of merge.

1. Three-way merge: If the main branch has progressed since the feature branch was created, Git creates a new "merge commit" that combines the changes from both branches.

What is a Merge Conflict and How to Resolve

Merge conflicts occur when Git can't automatically merge changes from different branches. This typically happens when:

1. Changes in different branches modify the same line of code
2. One branch deletes a file while another modifies it
3. Both branches add a file with the same name but different content

When a merge conflict occurs, Git will notify you and mark the conflicts in your files.

$ git merge feature/navbar
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Resolving Conflicts

When you open a file with conflicts, you'll see sections marked like this:

<<<<<<< HEAD
<h1>Welcome to Our Website</h1>
=======
<h1>Welcome to Our Awesome Site</h1>
>>>>>>> feature/navbar

Depending on your editor, the conflict might be color-coded, something like this:

To resolve the conflict:

1. Decide which version to keep, or create a combined version
2. Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
3. Save the file
4. Add the resolved files with git add
5. Complete the merge with git commit

# After resolving conflicts manually in your editor
$ git add index.html
$ git commit -m "Merge feature/navbar, resolve welcome message conflict"

⚠️ Note: For complex merge conflicts, graphical tools can be helpful. Use git mergetool to launch a configured visual merge tool.

For more detailed information on handling merge conflicts, see our dedicated guide: Git Merge Conflicts

What is the difference between a branch and a fork?

While branches and forks might seem similar, they serve different purposes and work differently:

Branches

• Location: Exist within a repository
• Purpose: Separate lines of development within a project
• Access Control: Subject to the same access controls as the repository
• Best for: Feature development, bug fixes, and experiments within a team

Forks

• Location: Exist as separate repositories under different GitHub accounts
• Purpose: Allow independent development or contributions to projects you don't have write access to
• Access Control: You have full control over your fork
• Best for: Contributing to open-source projects or making major divergent changes

Creating a Fork

To create a fork, click the Fork button on the top right of a repository's page on GitHub. This creates a full copy of the repository in your GitHub account.

# After forking on GitHub, clone your fork locally
$ git clone https://github.com/your-username/forked-repository.git

# Add the original repository as a remote called "upstream"
$ git remote add upstream https://github.com/original-owner/original-repository.git

# Verify remotes
$ git remote -v
origin  https://github.com/your-username/forked-repository.git (fetch)
origin  https://github.com/your-username/forked-repository.git (push)
upstream  https://github.com/original-owner/original-repository.git (fetch)
upstream  https://github.com/original-owner/original-repository.git (push)

💡 definitions:

remote repository: The repository that you forked from upstream: The original repository that you forked from (not technically "yours") origin: Your forked repository

Best Practices for Working with Branches

1. Keep branches focused: Each branch should represent a single feature or fix
2. Keep branches short-lived: Merge or delete branches once their purpose is fulfilled
3. Update branches regularly: Pull changes from the main branch to avoid difficult merges later
4. Use descriptive names: Name branches according to what they contain (e.g., feature/login, bugfix/header)
5. Delete merged branches: Clean up by deleting branches after they're merged

📝 Note: Your organization's best practices may vary from these, but they should be consistent and meaningful.

# Delete a branch after merging
$ git branch -d feature/login
Deleted branch feature/login (was a1b2c3d).

# Force delete an unmerged branch (use with caution)
$ git branch -D abandoned-feature
Deleted branch abandoned-feature (was e5f6g7h).

Further Reading

• Git Merge Conflicts - Detailed guide on resolving conflicts
• Git Workflow Recommendation - Recommended workflows for different scenarios
• Git Pull Requests - How to use pull requests for code review and merging