Day 25 of #90DaysOfDevOps – Understanding Git Reset, Git Revert & Branching Strategies
Introduction
Today's focus was on one of the most important Git skills: undoing mistakes safely.
In real-world projects, mistakes happen all the time. Files get modified accidentally, wrong commits are created, and changes sometimes need to be rolled back. Git provides multiple ways to handle these situations, and understanding the difference between them is critical.
Today I explored:
Git Reset (
--soft,--mixed,--hard)Git Revert
Git Reflog
GitFlow
GitHub Flow
Trunk-Based Development
Git Reset
To understand reset, I first created multiple commits in my practice repository.
Current history:
git log --oneline
Output:
Commit C
Commit B
Commit A
The goal was to move backwards through history and observe what happens to the changes.
Git Reset --soft
Command:
git reset --soft HEAD~1
Result:
Latest commit removed from history
File changes remained intact
Changes stayed staged
Git status showed:
Changes to be committed
modified: devops.sh
Observation
The commit disappeared, but all changes were ready to be committed again.
This is useful when:
Commit message is wrong
You want to combine commits
You need to recommit changes differently
Git Reset --mixed
Command:
git reset --mixed HEAD~1
Result:
Commit removed
Changes preserved
Files became unstaged
Git displayed:
Changes not staged for commit
modified: devops.sh
Observation
The work was not lost, but Git removed it from the staging area.
This is Git's default reset mode.
Useful when:
You accidentally staged files
You want to review changes before committing again
Git Reset --hard
Command:
git reset --hard HEAD~1
Result:
HEAD is now at ca36c40 hello.txt
Git status:
nothing to commit, working tree clean
Observation
This time both the commit and file changes disappeared completely.
Unlike soft and mixed reset, the modifications were removed from the working directory.
Why is it Dangerous?
Because deleted work cannot be recovered easily unless it exists in the reflog.
This makes --hard the most destructive reset option.
Understanding Git Revert
After learning reset, I explored a safer alternative.
Command:
git revert 30d035d
Git created:
Revert "Docker"
Instead of deleting history, Git generated a brand-new commit that reversed the earlier changes.
What Happened?
Before:
Docker
After:
Docker
Revert "Docker"
Both commits remain visible in the repository history.
This means the project history remains complete and transparent.
Why Revert is Safer
Viewing history:
git log --oneline
Output:
Revert "Docker"
hello.txt
Docker
Notice that the original commit still exists.
Nothing was rewritten.
Instead, Git added another commit that undoes the previous one.
This is why revert is preferred on shared branches.
Reset vs Revert
| Feature | Git Reset | Git Revert |
|---|---|---|
| Purpose | Move branch pointer backwards | Create a new commit that reverses changes |
| Changes history | Yes | No |
| Removes commits | Yes | No |
| Safe for shared branches | No | Yes |
| Best used for | Local cleanup | Public repositories |
| Risk level | High | Low |
Git Reflog – The Safety Net
One of the most useful discoveries today was:
git reflog
Reflog tracks every action performed in Git.
Even after a hard reset, reflog can help recover lost commits.
Example:
git reflog
Output:
HEAD@{0}
HEAD@{1}
HEAD@{2}
Recover:
git reset --hard HEAD@{1}
This makes reflog one of Git's most powerful recovery tools.
Branching Strategies
Modern teams don't all use Git in the same way.
Different projects require different workflows.
Today I explored three common branching strategies.
GitFlow
GitFlow uses multiple long-lived branches.
Structure:
main
│
develop
├── feature/*
├── release/*
└── hotfix/*
Used For
Large organizations
Enterprise applications
Scheduled releases
Pros
Structured workflow
Clear separation of development stages
Supports release management
Cons
More complex
Many branches to maintain
GitHub Flow
GitHub Flow keeps things simple.
Structure:
main
└── feature-branch
└── Pull Request
└── Merge
Used For
Startups
SaaS products
Continuous deployment environments
Pros
Easy to understand
Fast development cycle
Minimal overhead
Cons
- Less structured for large release cycles
Trunk-Based Development
All developers work close to the main branch.
Structure:
main
├── short-lived feature
├── short-lived feature
└── short-lived feature
Used For
High-performance engineering teams
CI/CD environments
Large cloud-native organizations
Pros
Faster integration
Fewer merge conflicts
Excellent for continuous delivery
Cons
Requires discipline
Strong automated testing needed
Which Strategy Would I Choose?
Startup Shipping Fast
GitHub Flow or Trunk-Based Development
Reason:
Faster releases
Simpler workflow
Better suited for continuous deployment
Large Team with Scheduled Releases
GitFlow
Reason:
Better release management
Supports multiple development stages
Easier coordination across teams
Commands Learned Today
git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1
git revert <commit-id>
git reflog
Key Learnings
1. Reset Rewrites History
Soft, mixed, and hard reset move the branch pointer backwards, but each treats changes differently.
2. Revert Preserves History
Revert never deletes commits. It creates a new commit that reverses previous changes.
3. Hard Reset is Dangerous
A hard reset removes both commits and working directory changes.
4. Reflog Can Save You
Even after mistakes, reflog often allows recovery.
5. Branching Strategy Matters
Different teams choose GitFlow, GitHub Flow, or Trunk-Based Development depending on release cycles and team size.
Conclusion
Day 25 was one of the most practical Git sessions so far.
Understanding the difference between Reset and Revert made it clear when to rewrite history and when to preserve it. Learning branching strategies also provided insight into how real engineering teams organize development and releases.
The biggest takeaway from today:
Reset changes history. Revert changes code.
Knowing when to use each can prevent major problems in collaborative projects.
Day 25 completed. 🚀
