DEV Community

Cover image for Git Branching & Merging: The Foundation of Team Collaboration in Git
Md Mohiuddin
Md Mohiuddin

Posted on

Git Branching & Merging: The Foundation of Team Collaboration in Git

#github #git #beginners #devops

Git becomes truly powerful when multiple developers can work on different features at the same time without interfering with each other's work. That's exactly what branching and merging solve.

In this article, we'll explore how Git branches work, how to merge changes safely, resolve conflicts, collaborate through GitHub, and understand the workflow used by modern development teams.

Why Branching Matters

Imagine a team working on a web application:

  • One developer is building a login page.
  • Another is fixing a payment bug.
  • A third is improving performance.

If everyone worked directly on the same branch, changes would constantly collide, making development chaotic and risky.

Git branching allows developers to work independently in isolated environments and merge their changes only when they're ready.

This is the foundation of modern software collaboration.

What Is a Git Branch?

Many beginners think a branch is a complete copy of a project.

It isn't.

A Git branch is simply a lightweight pointer to a commit.

Consider a project history:

A --- B --- C
              ^
            main
Enter fullscreen mode Exit fullscreen mode

Here, main points to the latest commit (C).

When you create a new branch:

A --- B --- C
              ^
            main
              ^
        feature-login
Enter fullscreen mode Exit fullscreen mode

Git creates another pointer.

No files are copied.

No duplicate project is created.

Just another reference to the same commit.

How Branches Grow

Once you switch to the new branch and start making commits:

main:    A --- B --- C
                        ^
                      main

feature-login:
                    D --- E
                          ^
                    feature-login
Enter fullscreen mode Exit fullscreen mode

Only the feature branch moves forward.

The main branch remains unchanged.

This allows you to experiment, develop features, and fix bugs without affecting the stable codebase.

Why Git Branches Are So Fast

Since a branch is only a pointer:

  • Creating a branch takes milliseconds.
  • Switching branches is extremely fast.
  • Large repositories don't become slower when creating branches.

Unlike older version control systems where branching was expensive, Git encourages creating branches frequently.

Creating a branch for every feature or bug fix is considered a best practice.

Creating and Switching Branches

View Existing Branches 

git branch
Enter fullscreen mode Exit fullscreen mode

Output:

* main
Enter fullscreen mode Exit fullscreen mode

The * indicates the current branch.

Create a New Branch 

git branch feature-login
Enter fullscreen mode Exit fullscreen mode

This creates the branch but does not switch to it.

Switch to a Branch 

git switch feature-login
Enter fullscreen mode Exit fullscreen mode

Or:

git checkout feature-login
Enter fullscreen mode Exit fullscreen mode

Create and Switch in One Command 

git switch -c feature-login
Enter fullscreen mode Exit fullscreen mode

Older equivalent:

git checkout -b feature-login
Enter fullscreen mode Exit fullscreen mode

Delete a Branch

Safe delete:

git branch -d feature-login
Enter fullscreen mode Exit fullscreen mode

Force delete:

git branch -D feature-login
Enter fullscreen mode Exit fullscreen mode

Use force deletion carefully because it can remove unmerged work.

Branch Naming Best Practices

Professional teams typically follow naming conventions.

Examples:

feature/PROJ-123-user-authentication

bugfix/PROJ-456-fix-login-error

hotfix/critical-payment-issue
Enter fullscreen mode Exit fullscreen mode

Benefits:

  • Easy to understand purpose
  • Connected to Jira tickets
  • Easier code reviews
  • Better repository organization

Understanding Git Merge

Once your work is complete, you'll want to bring it back into main.

First switch to the target branch:

git switch main
Enter fullscreen mode Exit fullscreen mode

Then merge:

git merge feature-login
Enter fullscreen mode Exit fullscreen mode

Git now combines both histories.

Fast-Forward Merge

This happens when no new commits exist on main.

Before merge:

main:
A --- B --- C

feature:
A --- B --- C --- D --- E
Enter fullscreen mode Exit fullscreen mode

After merge:

A --- B --- C --- D --- E
                              ^
                      main & feature
Enter fullscreen mode Exit fullscreen mode

Git simply moves the main pointer forward.

No special merge commit is created.

This is called a Fast-Forward Merge.

Three-Way Merge

Real projects usually look like this:

main:
A --- B --- C

feature:
      \
       D --- E
Enter fullscreen mode Exit fullscreen mode

While you were working, someone else added commits to main.

Git must now combine both histories.

Result:

A --- B --- C ----------- M
          \             /
           D --- E ----
Enter fullscreen mode Exit fullscreen mode

M is a merge commit.

It contains two parent commits:

  • One from main
  • One from feature

This process is called a Three-Way Merge.

What Is a Merge Conflict?

Sometimes Git can't determine which change should win.

Example:

Main Branch 

Welcome to our application
Enter fullscreen mode Exit fullscreen mode

Feature Branch 

Welcome to our awesome application
Enter fullscreen mode Exit fullscreen mode

Both modified the same line.

Git stops and asks for help.

This is called a Merge Conflict.

What a Conflict Looks Like

Git inserts markers directly into the file:

<<<<<<< HEAD
Welcome to our application
=======
Welcome to our awesome application
>>>>>>> feature-login
Enter fullscreen mode Exit fullscreen mode

Understanding the Markers 

<<<<<<< HEAD
Enter fullscreen mode Exit fullscreen mode

Current branch version.

=======
Enter fullscreen mode Exit fullscreen mode

Separator.

>>>>>>> feature-login
Enter fullscreen mode Exit fullscreen mode

Incoming branch version.

Resolving Merge Conflicts

Step 1: Open the File

Review both versions.

Step 2: Decide the Final Content

Example:

Welcome to our awesome application
Enter fullscreen mode Exit fullscreen mode

Step 3: Remove Conflict Markers

Delete:

<<<<<<<
=======
>>>>>>>
Enter fullscreen mode Exit fullscreen mode

Step 4: Stage the Resolved File 

git add app.txt
Enter fullscreen mode Exit fullscreen mode

Step 5: Complete the Merge 

git commit
Enter fullscreen mode Exit fullscreen mode

Git automatically generates a merge message.

Don't Fear Merge Conflicts

Many beginners panic when they see conflicts.

Don't.

Merge conflicts are:

  • Normal
  • Expected
  • Common in every team

Even senior engineers resolve conflicts regularly.

The skill isn't avoiding them.

The skill is understanding and resolving them confidently.

Understanding Remote Repositories

Everything so far has been local.

To collaborate, we use remote repositories hosted on platforms like:

  • GitHub
  • GitLab
  • Bitbucket

The most common remote name is:

origin
Enter fullscreen mode Exit fullscreen mode

Pushing Changes to GitHub

Upload local commits:

git push origin main
Enter fullscreen mode Exit fullscreen mode

This sends your local commits to GitHub.

Pulling Changes From GitHub

Download and merge changes:

git pull origin main
Enter fullscreen mode Exit fullscreen mode

This keeps your local branch up to date.

What git pull Actually Does

Many developers use git pull daily without knowing what it really does.

Internally:

git pull
=
git fetch
+
git merge
Enter fullscreen mode Exit fullscreen mode

Fetch

Downloads new commits.

git fetch
Enter fullscreen mode Exit fullscreen mode

No files are changed.

No merge occurs.

Git simply updates its knowledge of the remote repository.

Merge

After fetching:

git merge
Enter fullscreen mode Exit fullscreen mode

Git combines the changes into your current branch.

Why Pull Before Push?

Imagine:

  1. You create new commits.
  2. A teammate pushes changes first.
  3. You try pushing.

Git rejects it:

! [rejected] main -> main (fetch first)
Enter fullscreen mode Exit fullscreen mode

Git is protecting shared history.

Solution:

git pull origin main
Enter fullscreen mode Exit fullscreen mode

Resolve conflicts if necessary.

Then:

git push origin main
Enter fullscreen mode Exit fullscreen mode

Understanding GitHub Flow

GitHub Flow is one of the most widely used collaboration workflows.

It is simple, lightweight, and works perfectly with CI/CD pipelines.

Step 1: Create a Branch 

git switch -c feature-login
Enter fullscreen mode Exit fullscreen mode

Step 2: Make Commits

Example:

git add .
git commit -m "feat: add login page"
Enter fullscreen mode Exit fullscreen mode

Step 3: Push the Branch 

git push origin feature-login
Enter fullscreen mode Exit fullscreen mode

This backs up your work and makes it visible to teammates.

Step 4: Open a Pull Request (PR)

A Pull Request is a request to merge your branch into main.

It allows:

  • Discussion
  • Review
  • Feedback
  • Collaboration

Step 5: Code Review

Teammates review:

  • Code quality
  • Architecture
  • Bugs
  • Security concerns

Suggestions are discussed before merging.

Step 6: Automated Checks Run

Modern CI/CD pipelines automatically run:

  • Unit tests
  • Linting
  • Security scans
  • Build verification

Only passing code can be merged.

Step 7: Merge Into Main

Once approved:

feature-login → main
Enter fullscreen mode Exit fullscreen mode

The changes become part of the main codebase.

Step 8: Deploy

Many organizations automatically deploy after merging into main.

Merge → CI/CD Pipeline → Deployment
Enter fullscreen mode Exit fullscreen mode

Step 9: Delete the Branch

After merging:

git branch -d feature-login
Enter fullscreen mode Exit fullscreen mode

The branch has served its purpose.

Visualizing GitHub Flow 

main:
A --- B ----------------------- M
          \                   /
           C --- D --- E ----
                feature-login
Enter fullscreen mode Exit fullscreen mode

Workflow:

  1. Create branch
  2. Commit changes
  3. Push branch
  4. Open PR
  5. Review
  6. Run automated checks
  7. Merge
  8. Deploy
  9. Delete branch

Why GitHub Flow Is So Popular

Simplicity

Only one long-lived branch:

main
Enter fullscreen mode Exit fullscreen mode

Everything else is temporary.

CI/CD Friendly

Every Pull Request becomes a checkpoint for:

  • Testing
  • Validation
  • Security scanning

Encourages Code Reviews

Changes reach production only after another engineer reviews them.

This improves:

  • Quality
  • Knowledge sharing
  • Team collaboration

Key Takeaways

  • A branch is simply a movable pointer to a commit.
  • Branches allow isolated development without affecting main.
  • Merging combines work from multiple branches.
  • Fast-forward merges occur when histories haven't diverged.
  • Three-way merges create a merge commit when histories differ.
  • Merge conflicts happen when Git can't decide between overlapping changes.
  • git pull = git fetch + git merge.
  • git push shares your commits with a remote repository.
  • GitHub Flow is the modern workflow used by most teams and integrates naturally with CI/CD.

Master branching and merging, and you've learned the workflow that powers nearly every professional software team in the world.

Happy Coding! 🚀

Top comments (0)