Understanding Git Branching and Merging: How Multiple Developers Collaborate on One Project

Toby Jones — Sat, 14 Nov 2026 14:36:08 +0000

As part of my journey into DevOps engineering, I've been working on understanding how developers collaborate using Git and GitHub.

One important concept I've been practicing is Git branching and merging.

In a real development environment, multiple developers can work on the same application simultaneously. Rather than everyone modifying the main branch directly, developers work on separate branches and eventually integrate their changes.

Here's what I learned.

1. Why do we use Git branches?

Imagine a team with three developers:

Developer A is working on new features.
Developer B is fixing bugs.
Developer C is implementing updates.

Instead of everyone working directly on the main branch, each developer can work independently.

For example:

git branch development
git branch patches
git branch updates

Switch between branches using:

git checkout development

This allows developers to work on different parts of a project without immediately affecting the main codebase.

2. Understanding merge conflicts

One interesting part of the exercise was understanding how merge conflicts happen.

Imagine two developers modifying the same file, index.html, on different branches.

Developer A adds:

<h1>Welcome to my application</h1>

Developer B adds:

<h1>Welcome to our application</h1>

When both branches are merged, Git may encounter conflicting changes.

Git cannot automatically determine which version the team intends to keep.

This is where merge conflict resolution becomes important.

The engineer must inspect the conflicting sections, decide how the changes should be combined, and commit the resolution.

An important distinction: using different filenames can prevent certain filename-related conflicts, but it doesn't eliminate merge conflicts generally.

3. Practising Git merging

During the practical session, I worked with multiple branches:

development
updates
patches
security

The objective was to make changes on separate branches and eventually bring the work together into the main branch.

The basic workflow looked like this:

Step 1: Switch to the main branch

git checkout main

Step 2: Pull the latest changes

git pull origin main

Step 3: Merge the development branch

git merge development

Step 4: Merge the remaining branches

git merge updates
git merge patches

Merging branches individually makes it easier to identify which integration introduces a conflict.

4. What happens when a merge conflict occurs?

When Git encounters conflicting changes, it marks the affected sections of the file.

You need to:

Identify the conflicting file.
Inspect the conflicting sections.
Decide which changes to retain or combine.
Remove the conflict markers.
Stage the resolved file.
Commit the resolution.

For example:

git add index.html
git commit -m "Resolve merge conflict in index.html"

5. What I'm taking away from this exercise

A major takeaway is that Git is more than a tool for storing code.

It provides a structured way for engineering teams to collaborate, manage changes and integrate contributions.

As someone transitioning into DevOps engineering, understanding these workflows is important because they form part of the foundation of CI/CD.

What's next on my learning list?

I want to take this further by exploring:

Pull Requests (PRs)
GitHub Actions
Automated testing before merging
Branch protection rules
CI/CD pipeline triggers
Automated deployment after successful merges

The goal is to understand how code moves from a developer's local environment to a production environment.

One practical session at a time.

DevOps #Git #GitHub #CICD #CloudEngineering #LearningInPublic