Mastering Git Flow For Newbie

Mastering Git Flow For Newbie
Photo by Yancy Min / Unsplash

The Ultimate Guide for Solo & Collaborative Work

Arsitektur branching, conventional commits, dan gimana cara manage release ala corporate—buat lo yang solo player atau yang udah main di enterprise level.

Honestly, di dunia software engineering jaman now, Git tuh bukan cuma sekadar version control system biasa—it's literally the backbone of our collaboration. Kalau lo paham workflow yang proper, development bakal smooth banget dan lo bakal terhindar dari merge conflict yang bikin burnout. Tulisan ini basically comprehensive guide buat handle versioning kayak professional, mau pas lagi build project sendirian atau pas lagi team-up skala besar.


Daftar Isi

  1. Solo Workflow: Efficiency & Discipline
  2. Collaborative Workflow: Corporate Scale
  3. Neat Hotfix Management
  4. Commit Message Standard
  5. Extra Best Practices

1. Solo Workflow: Efficiency & Discipline

Kerja sendirian emang ngasih flexibility yang tinggi, tapi kalau nggak ada clear structure, history project lo bakal berantakan parah. Kuncinya sih habit: biasain pake professional protocol dari awal, jangan nunggu project-nya scaling up dulu.

Simple Branching Structure

Branch Fungsi
main Holy branch, man. Kode di sini strictly harus stabil dan ready to deploy.
feat/nama-fitur Basically workspace lo. Tiap ada feature baru, kerjain di sini sebelum di-merge ke main.

💡 Solo Tips: Always pake feature branch walau lo lagi ngoding sendirian di text editor Anti-Gravity. Ini ngebantu banget buat isolate bugs dan gampang buat rollback misal eksperimen lo failed.

# 1. Create new feature branch dari main
git checkout -b feat/setup-database

# 2. Do the work, terus commit
git add .
git commit -m "feat: implement supabase connection"

# 3. Balik ke main dan merge
git checkout main
git merge feat/setup-database

# 4. Delete branch-nya kalau udah beres
git branch -d feat/setup-database

2. Collaborative Workflow: Corporate Scale

Nah, beda cerita kalau lo udah masuk environment office kayak pas nge-develop app skala gede. Lo bakal deal sama banyak developer, release schedule yang ketat, plus urgent hotfixes. Di stage ini, Git Flow lo harus super structured dan hierarchical.

Enterprise Branching Hierarchy

main
 └── dev
      ├── feat/JIRA-123/nama-fitur
      ├── chores/update-dependencies
      └── release/release-100
           └── hotfix/JIRA-444/fix-api-timeout

Branch Reference Table

Branch Fungsi Source dari
dev Main integration. Semua fitur baru masuk sini. main
release/xxx Persiapan deployment (e.g., release-100). Fokusnya pure buat final bugfixing. dev
feat/ Specific feature development (e.g., feat/JIRA-123/login). dev
hotfix/ Penyelamat hidup pas ada urgent issue di production atau release. release / main
chores/ Buat task non-fitur, like updating dependencies atau CI/CD configs. dev

3. Neat Hotfix Management

Bug di production tuh nggak kenal jadwal. Seringnya malah ketemu di branch release yang lagi on going. Proper hotfix flow itu crucial banget biar fix-nya nggak missing di next version.

Double-Merge Protocol

⚠️ IMPORTANT: Habis lo merge hotfix ke release-100, make sure lo merge juga ke dev biar versi release selanjutnya (misal release-120) nggak ngebawa bug yang sama.

Langkah-langkahnya:

  1. Pull branch hotfix/ dari release-100take note, bukan dari dev ya!
  2. Solve the issue, terus commit pake format yang bener.
  3. Merge balik ke release-100this goes to production.
  4. Merge juga ke dev — ini crucial step yang sering banget ke-skip.
# 1. Checkout dari release yang lagi error
git checkout release-100
git checkout -b hotfix/JIRA-444/fix-api-timeout

# 2. Fix the bug, then commit
git commit -m "fix/JIRA-444/adjust-timeout-duration"

# 3. Merge ke release (biar naik ke production)
git checkout release-100
git merge hotfix/JIRA-444/fix-api-timeout

# ⚡ DON'T FORGET: merge juga ke dev!
git checkout dev
git merge hotfix/JIRA-444/fix-api-timeout

# Cleanup
git branch -d hotfix/JIRA-444/fix-api-timeout

4. Commit Message Standard

Commit message yang messy bakal nyusahin banget pas debugging, code review, atau pas generate changelog. Biar rapi, kita apply Conventional Commits yang di-integrate sama kode JIRA.

Standard Format

[type]/[JIRA-CODE]/[descriptive commit message]

Commit Types

Type Kegunaan Contoh
feat New feature buat user feat/MOB-101/integrate-google-maps-sdk
fix Bug fixing fix/MOB-202/solve-crash-on-ios-13
hotfix Critical fix, harus deploy ASAP hotfix/JIRA-444/fix-api-timeout
refactor Code cleanup, nggak ngubah logic behavior refactor/MOB-310/clean-auth-service
chore Routine maintenance, under the hood stuff chore/MOB-303/update-cocoapods-dependencies

ℹ️ Consistent commit messages ini ngebantu banget biar tools macam semantic-release atau commitizen bisa auto-generate changelog dan version bumping secara otomatis.


5. Extra Best Practices

Punya branching structure sama commit convention doang tbh nggak cukup. Ini beberapa habits yang ngebedain senior dev sama yang lain.

⚛️ Atomic Commits

Jangan nyampur dua fitur beda di satu commit. Satu logical goal = satu commit. Ini bikin git bisect lebih efektif dan rollback jadi super presisi.

🚫 Avoid: "feat: add login + fix navbar + update readme"three things in one commit is a nightmare for everyone.

📋 Pull Request Hygiene

Tiap PR mandatory buat nyantumin:

  • Clear description soal apa yang di-change dan kenapa.
  • Step-by-step how to test the changes.
  • Screenshot kalau ada UI/UX changes.
  • Relevant labels dan assignee.

🔀 Rebase vs Merge

Rajin-rajin git rebase dev di feature branch lo biar history-nya tetep linear dan minimize conflicts pas final merge.

# Sync feature branch lo sama dev terbaru
git fetch origin
git rebase origin/dev

# Force push ke remote branch (karena history berubah)
git push --force-with-lease

🗜️ Squash Merge

Pas feature lo udah done, biasain pake squash merge buat nyatuin multiple minor commits jadi satu clean commit di branch dev.

git checkout dev
git merge --squash feat/JIRA-123/login
git commit -m "feat/JIRA-123/implement-login-flow"

🎯 Pro tip: Di GitHub/GitLab lo, set default action-nya ke Squash and Merge pas nge-close PR, so all devs automatically follow the same standard.


Cheat Sheet Summary

# Context Rules
1 Solo Always pake feature branch, merge ke main aja.
2 Enterprise Hierarchy maindevrelease / feat / hotfix.
3 Hotfix Always double-merge ke release DAN dev.
4 Commits Format [type]/[JIRA]/[desc] no compromise.
5 PR Full description, atomic, cantumin screenshot buat UI updates.
6 Merge Rebase frequently, squash merge pas PR done.

© 2026 Hamzhya's Git Flow Tutorial — Designed for Efficiency and Scalability