Chapter 72: DevOps Projects Part 2: Git Branching, Hooks, Conflicts, Semver, Monorepo and Gitea
72.1 Project 11: Branching strategy for a team (feature, release, hotfix)
Friends, a team without a branch plan fights over the same files. Today we set a clear plan: main stays shippable, feature branches for work, release for freeze, hotfix for production fire. We practice every command on a local bare repo.
मित्रांनो, branch plan नसलेली team एकाच files वर भांडते. आज clear plan: main shippable, feature branches, release freeze, hotfix for production. Local bare repo वर प्रत्येक command practice करू.
दोस्तों, branch plan के बिना team एक ही files पर लड़ती है. आज clear plan: main shippable, feature branches, release freeze, hotfix for production. Local bare repo पर हर command practice करेंगे.
What you will build in this project
- A bare practice remote on disk.
- main protected by habit (no direct commits).
- feature, release and hotfix branch flows.
- Merge back with a short proof log.
1. Start from a real company story
At Persistent Systems in Pune, eight developers pushed straight to main. A half-done payment fix shipped on Friday night.
Customers could not pay for 40 minutes. Rough brand cost: about ₹9 lakh in failed checkouts and support overtime.
Asha locked main, introduced feature and hotfix branches, and made every merge go through a reviewed pull request on the company Git host.
Today we build that branching habit on a practice bare repo, with no cloud account needed.
Ravindra Bagale's Tip
Many students commit straight to main because it is faster. That speed costs the company later. Always branch first. Keep that habit.
खूप students main वर थेट commit करतात कारण जलद वाटते. ती speed नंतर कंपनीला महाग पडते. नेहमी आधी branch काढा. सवय ठेवा.
बहुत students main पर सीधे commit करते हैं क्योंकि तेज़ लगता है. वह speed बाद में कंपनी को महंगी पड़ती है. हमेशा पहले branch बनाएँ. आदत रखिए.
2. Start and prepare
Step 1: Create bare remote
Why: Teams need a shared remote. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git init --bare. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 1: bare
Type this:
mkdir -p /tmp/gitlab && git init --bare /tmp/team.git && ls /tmp/team.git/HEAD
You will see:
/tmp/team.git/HEAD
What it means: Bare remote ready. No working tree.
Example 2: clone
Type this:
rm -rf /tmp/shop && git clone /tmp/team.git /tmp/shop && cd /tmp/shop && git remote -v
You will see:
origin /tmp/team.git (fetch)
origin /tmp/team.git (push)
What it means: Local clone points at bare remote.
Example 3: first commit
Type this:
cd /tmp/shop && git config user.email 'asha@persistent.example' && git config user.name 'Asha' && printf '%s\n' 'shop api' > README.md && git add README.md && git commit -m 'chore: initial readme' && git branch -M main && git push -u origin main
You will see:
[main (root-commit) a1b2c3d] chore: initial readme
Branch 'main' set up to track 'origin/main'.
What it means: main exists on the remote.
Step 2: Clone and set identity
Why: Clone gives a working copy. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git clone and config. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 4: whoami
Type this:
cd /tmp/shop && git config --get user.name && git config --get user.email
You will see:
Asha
asha@persistent.example
What it means: Identity set for this repo only.
Example 5: status
Type this:
cd /tmp/shop && git status -sb
You will see:
## main...origin/main
What it means: Clean and tracking.
Example 6: log1
Type this:
cd /tmp/shop && git log --oneline -1
You will see:
a1b2c3d chore: initial readme
What it means: One commit on main.
Step 3: Protect main habit
Why: Nobody commits on main directly. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: Refuse direct commits. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 7: refuse note
Type this:
cd /tmp/shop && echo 'rule: never commit on main; always branch first' | tee /tmp/branch-rule.txt && cat /tmp/branch-rule.txt
You will see:
rule: never commit on main; always branch first
What it means: Team rule written down.
Example 8: show branch
Type this:
cd /tmp/shop && git branch -vv
You will see:
* main a1b2c3d [origin/main] chore: initial readme
What it means: Only main for now.
Example 9: fetch
Type this:
cd /tmp/shop && git fetch origin && echo fetched
You will see:
fetched
What it means: Remote in sync.
3. Build the main pieces
Step 4: Start a feature branch
Why: feature names the task. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git switch -c. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 10: feature
Type this:
cd /tmp/shop && git switch -c feature/add-health && git branch --show-current
You will see:
feature/add-health
What it means: New branch for one task.
Example 11: file
Type this:
cd /tmp/shop && printf '%s\n' 'ok' > health.txt && git status -s
You will see:
?? health.txt
What it means: Untracked file.
Example 12: list
Type this:
cd /tmp/shop && git branch
You will see:
main
* feature/add-health
What it means: Two local branches.
Step 5: Commit on feature
Why: Small commits are easy to review. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git commit. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 13: add
Type this:
cd /tmp/shop && git add health.txt && git commit -m 'feat: add health file' && git log --oneline -2
You will see:
b2c3d4e feat: add health file
a1b2c3d chore: initial readme
What it means: Feature commit on top.
Example 14: push feature
Type this:
cd /tmp/shop && git push -u origin feature/add-health
You will see:
Branch 'feature/add-health' set up to track 'origin/feature/add-health'.
What it means: Remote sees the feature.
Example 15: diff main
Type this:
cd /tmp/shop && git diff main...HEAD --stat
You will see:
health.txt | 1 +
1 file changed, 1 insertion(+)
What it means: Only the feature file.
Step 6: Merge feature to main
Why: Merge brings the work home. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git merge. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 16: back main
Type this:
cd /tmp/shop && git switch main && git merge --no-ff feature/add-health -m 'merge: feature/add-health' && git log --oneline -3
You will see:
c3d4e5f merge: feature/add-health
b2c3d4e feat: add health file
a1b2c3d chore: initial readme
What it means: --no-ff keeps the merge bubble for history.
Example 17: push main
Type this:
cd /tmp/shop && git push origin main && echo pushed
You will see:
pushed
What it means: main updated on remote.
Example 18: delete local feature
Type this:
cd /tmp/shop && git branch -d feature/add-health && git branch
You will see:
* main
What it means: Local feature removed after merge.
4. Automate and verify
Step 7: Cut a release branch
Why: release freezes the set. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git switch -c release. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 19: release
Type this:
cd /tmp/shop && git switch -c release/1.0.0 && printf '%s\n' '1.0.0' > VERSION && git add VERSION && git commit -m 'chore: freeze 1.0.0' && git push -u origin release/1.0.0
You will see:
Branch 'release/1.0.0' set up to track 'origin/release/1.0.0'.
What it means: Release branch frozen with a version file.
Example 20: show
Type this:
cd /tmp/shop && cat VERSION && git log --oneline -1
You will see:
1.0.0
d4e5f6a chore: freeze 1.0.0
What it means: Version pinned on release.
Example 21: branches
Type this:
cd /tmp/shop && git branch -a | head -10
You will see:
* release/1.0.0
main
remotes/origin/main
remotes/origin/feature/add-health
remotes/origin/release/1.0.0
What it means: Release visible.
Step 8: Tag the release
Why: Tags mark what shipped. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git tag. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 22: tag
Type this:
cd /tmp/shop && git tag -a v1.0.0 -m 'release 1.0.0' && git push origin v1.0.0 && git show v1.0.0 --stat | head -5
You will see:
tag v1.0.0
Tagger: Asha
release 1.0.0
What it means: Annotated tag pushed.
Example 23: list tags
Type this:
cd /tmp/shop && git tag -l
You will see:
v1.0.0
What it means: One release tag.
Example 24: describe
Type this:
cd /tmp/shop && git describe --tags
You will see:
v1.0.0
What it means: HEAD is exactly the tag.
Step 9: Start a hotfix
Why: hotfix patches prod. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git switch -c hotfix. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 25: hotfix from tag
Type this:
cd /tmp/shop && git switch -c hotfix/1.0.1 v1.0.0 && printf '%s\n' 'ok-fixed' > health.txt && git add health.txt && git commit -m 'fix: health text' && echo on_hotfix
You will see:
on_hotfix
What it means: Hotfix cut from the shipped tag.
Example 26: bump
Type this:
cd /tmp/shop && printf '%s\n' '1.0.1' > VERSION && git add VERSION && git commit -m 'chore: bump 1.0.1' && git log --oneline -2
You will see:
f6a7b8c chore: bump 1.0.1
e5f6a7b fix: health text
What it means: Patch commits on hotfix.
Example 27: tag patch
Type this:
cd /tmp/shop && git tag -a v1.0.1 -m 'hotfix 1.0.1' && git push origin hotfix/1.0.1 v1.0.1 && echo tagged
You will see:
tagged
What it means: Patch tag on remote.
5. Harden and accept
Step 10: Merge hotfix both ways
Why: Both lines need the fix. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: merge to main and release. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 28: to main
Type this:
cd /tmp/shop && git switch main && git merge --no-ff hotfix/1.0.1 -m 'merge: hotfix/1.0.1 into main' && git push origin main && echo main_has_fix
You will see:
main_has_fix
What it means: main got the fix.
Example 29: to release
Type this:
cd /tmp/shop && git switch release/1.0.0 && git merge --no-ff hotfix/1.0.1 -m 'merge: hotfix/1.0.1 into release' && git push origin release/1.0.0 && echo release_has_fix
You will see:
release_has_fix
What it means: release line also has the fix.
Example 30: health on main
Type this:
cd /tmp/shop && git switch main && cat health.txt
You will see:
ok-fixed
What it means: Proof on main.
Step 11: Show the graph
Why: Graph proves history. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git log --graph. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 31: graph
Type this:
cd /tmp/shop && git log --oneline --graph --decorate -12
You will see:
* merge hotfix
|\
| * chore bump
| * fix health
|/
* merge feature
...
What it means: Graph shows feature and hotfix bubbles.
Example 32: remote tags
Type this:
cd /tmp/shop && git ls-remote --tags origin | awk '{print $2}'
You will see:
refs/tags/v1.0.0
refs/tags/v1.0.1
What it means: Both tags on remote.
Example 33: branches remote
Type this:
cd /tmp/shop && git ls-remote --heads origin | awk '{print $2}'
You will see:
refs/heads/main
refs/heads/feature/add-health
refs/heads/release/1.0.0
refs/heads/hotfix/1.0.1
What it means: All four roles present.
Step 12: Acceptance checklist
Why: Asha signs off when these pass. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: All green. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 34: rule file
Type this:
test -f /tmp/branch-rule.txt && echo rule_ok
You will see:
rule_ok
What it means: Team rule kept.
Example 35: main clean
Type this:
cd /tmp/shop && git switch main && git status -sb
You will see:
## main...origin/main
What it means: Clean.
Example 36: Sign-off
Type this:
echo 'Asha: PASS'
You will see:
Asha: PASS
What it means: Done.
Check yourself
Q1. Who fixed the Persistent Systems chaos?
Asha
Q2. Branch that stays shippable?
main
Q3. Prefix for task work?
feature/
Q4. Prefix for production fire?
hotfix/
Q5. Where does the bare remote live in the lab?
/tmp/team.git
Q6. Command to switch branch?
git switch
Friends, you practiced feature, release and hotfix flows on a bare remote. Did you understand? Let us try it once more. Create one more feature branch, open a merge, and write the three-line proof in your notebook.
मित्रांनो, तुम्ही bare remote वर feature, release आणि hotfix flow practice केला. आणखी एक feature branch काढून merge करा.
दोस्तों, आपने bare remote पर feature, release और hotfix flow practice किया. एक और feature branch बनाकर merge करें.
Lab: try at home
- Create the bare remote and clone.
- Protect main by habit.
- Ship a feature via merge.
- Cut a release branch and tag.
- Ship a hotfix and merge both ways.
Recap
- main stays shippable.
- One task per feature branch.
- release freezes for QA.
- hotfix patches production fast.
- Merge hotfix back to main and release.