Git Adventures --- Part 1: Five Developers, One Repo, and the "It Works on My Machine" Era

Search for a command to run...

No comments yet. Be the first to comment.
**Git Workflow Stories** is a practical Git learning series told through real developer scenarios. Instead of dry documentation, this series follows a team of developers working on the same project — creating repositories, building features, fixing bugs, resolving conflicts, and collaborating through pull requests. Each chapter introduces Git concepts in the exact situations where they appear in real development work. You will see how commands like `clone`, `branch`, `commit`, `merge`, `rebase`, `stash`, `reset`, and many others are used during a normal developer's day. If you’ve ever wondered *how Git is actually used inside a real team workflow*, this series will walk you through it step by step. By the end of the series, you’ll not only understand Git commands — you’ll understand the workflow behind them.
In Part 1, everything was clean. Repository created. Project initialized. Branches created. Team motivated. That illusion lasted exactly one day. Because on Day 2, the team learned an important truth:
In Part 1, everything was clean. Repository created. Project initialized. Branches created. Team motivated. That illusion lasted exactly one day. Because on Day 2, the team learned an important truth:

As developers, we keep discovering tools that quietly make our lives easier.Not flashy. Not hyped. Just… effective. These are three tools I keep coming back to because they remove friction from my workflow.They save time, reduce mental load, and let ...

🚀I’ve been working with React Native for about 4 years now, and one thing I’ve learned the hard way is this:Nothing stays permanent. Libraries get deprecated.Best practices change.Things that were “recommended” last year suddenly feel wrong today. A...

Every software project begins the same way.
Someone says, "Let's build something amazing."
Ten minutes later, someone asks:
"Wait... who created the Git repo?"
This is the story of a five-person development team starting their first project together.
Meet the team.
Virat --- The Repo Master Responsible for repositories and access control.
Amaresh --- The Architect designs the project structure and keeps the codebase organised.
Johnny, Danny, Ronaldo --- The Feature Crew: Three developers who will build features, write code, and occasionally break things.
Today is Day 1.
And the project begins with the most important step in any software project.
Creating the repository.
Virat opens his terminal and announces that the project officially begins.
mkdir project-hyperdrive
cd project-hyperdrive
Now he initialises Git.
git init
Git responds:
Initialized empty Git repository
Behind the scenes, something important just happened.
Git created a hidden folder called:
.git
This folder stores everything Git needs:
commit history
branches
logs
references
repository metadata
Without .gitthe folder is just a normal directory.
With .git It becomes a version-controlled project.
Virat turns to Amaresh.
The repository exists now, but a repository without files is like a city without buildings.
Amaresh prepares the initial project structure on his machine.
He checks what Git sees.
git status
Output:
Untracked files:
README.md
src/
config/
Git sees the files but does not track them automatically.
Developers must tell Git which files should be tracked.
Virat created the repository on his machine, and Amaresh prepared the project on his laptop.
Johnny asks:
"How are we working in the same repository?"
Virat explains.
Local Repository → developer machines
Remote Repository → shared server
Virat connects his repository to the remote server.
git remote add origin https://company-repo/project.git
git push -u origin main
Amaresh connects his machine to the same repository.
git remote add origin https://company-repo/project.git
git pull origin main
Now both machines share the same Git history.
Amaresh stages the project files.
git add .
The dot (.) means add everything inside the current directory.
Git workflow:
Working Directory → Staging Area → Commit History
Staging allows developers to choose which files should go into the next commit.
Amaresh creates the first commit.
git commit -m "Initial project setup"
A commit is a snapshot of the project at a specific moment.
Each commit records:
changes
author
time
commit message
Virat grants repository access to the team.
Johnny clones the repository.
git clone https://company-repo/project.git
Danny checks the status.
git status
Output:
On branch main
Your branch is up to date with origin/main
Everyone is synchronised.
The main The branch must always remain stable.
Developers create branches for their work.
feat/login-system
feat/payment-module
bugfix/login-validation
bugfix/crash-on-start
hotfix/security-patch
hotfix/payment-crash
chore/update-dependencies
docs/setup-guide
refactor/auth-module
style/code-formatting
test/auth-tests
perf/query-optimization
release/v1.0
Workflow:
Create branch → Commit → Push → Pull Request → Review → Merge
Amaresh assigns tasks.
Johnny:
git checkout -b feat/authentication
Danny:
git checkout -b feat/profile-system
Ronaldo:
git checkout -b feat/service-integration
Three developers.
Three branches.
One repository.
And somewhere in the future...
A merge conflict is waiting.
What the team learned:
git init
git status
git add
git commit
git remote
git push
git clone
git branch
Branch naming examples:
feat/
bugfix/
hotfix/
docs/
chore/
refactor/
style/
test/
perf/
release/
In the next part, the team will learn:
PR creation
git log
git diff
git show
git stash
resolving merge conflicts
Follow the series for Part 2.
