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.
Top comments (0)