Git Workflow — Komanda İşi Üçün Branch Strategiyası

Git Workflow — Komanda İşi Üçün Branch Strategiyası

Salam, developer dostum! 👋

Gəl səninlə açıq danışaq: əgər hələ də bütün kodu main branch-ə birbaşa push edirsənsə, bu yazı sənin üçündür. Tək işləyəndə belə yanaşma keçər, amma 3-4 nəfərlik komandada — xüsusilə Bakıdakı outsource şirkətlərində və ya startuplarda — bu, mütləq conflict faciəsinə çevrilir.

Bu gün Azərbaycanda işləyən developerlərin real ehtiyaclarına uyğun Git workflow strategiyalarını, konkret əmrlərlə və praktiki misallarla izah edəcəyəm.

---

Niyə Branch Strategiyası Vacibdir?

Stack Overflow-nun 2024 Developer Survey-inə görə, professional developerlərin 87%-i versiya kontrolu üçün Git istifadə edir. Amma eyni sorğu göstərir ki, komandaların 42%-i merge conflict-lərə görə həftədə minimum 2-3 saat itirir.

Bakıda bir fintech startupda işləyən dostum bunu gözəl ifadə etmişdi: "Biz 5 developer idik, hamımız main-ə push edirdik. Bir gün production-da müştərinin balansı sıfırlandı. Səbəb? İki nəfərin eyni faylı eyni vaxtda dəyişməsi və merge conflict-in düzgün həll olunmaması."

Bu, nadir hadisə deyil. Gəl baxaq bu problemi necə həll edək.

---

Ən Populyar 3 Git Workflow

1. Git Flow (Klassik)

Ən strukturlaşdırılmış yanaşmadır. Böyük komandalar və release cycle-ı olan layihələr üçün idealdır.

Branch strukturu:

• main — production-dakı kod
• develop — development branch
• feature/* — yeni funksionallıq
• release/* — release hazırlığı
• hotfix/* — production bug fix

bashKopyala
# Yeni feature başlamaq
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# İşini gör, commit et
git add .
git commit -m "feat: add JWT authentication logic"
git commit -m "feat: add login endpoint"

# Feature hazır olanda develop-a merge et
git checkout develop
git merge --no-ff feature/user-authentication
git push origin develop

# Branch-i sil
git branch -d feature/user-authentication

Harada istifadə olunur? Bakıda bank layihələri üçün işləyən şirkətlər — məsələn, ABB, Kapital Bank kimi qurumların vendor komandaları adətən bu modeli seçir. Çünki release cycle ciddi testlərdən keçir.

2. GitHub Flow (Sadə və Effektiv)

Kiçik-orta komandalar üçün ən praktiki yanaşma. Bakıdakı əksər startuplar və 3-10 nəfərlik komandalar üçün mənim tövsiyəm budur.

Qaydalar sadədir:

1. main branch həmişə deploy oluna bilən vəziyyətdədir
2. Yeni iş üçün main-dən branch aç
3. Pull Request (PR) aç, review al
4. Review-dan sonra main-ə merge et
5. Dərhal deploy et

bashKopyala
# main-dən yeni branch
git checkout main
git pull origin main
git checkout -b feature/payment-integration

# İşini gör
git add .
git commit -m "feat: integrate payment gateway API"
git push origin feature/payment-integration

# GitHub/GitLab-da Pull Request aç
# Komanda yoldaşın review etsin
# Approve olandan sonra main-ə merge et

3. Trunk-Based Development

Google, Facebook kimi nəhəng şirkətlərin istifadə etdiyi model. Bütün developerlər birbaşa main (trunk) branch-ə çox kiçik, tez-tez commit edir. Feature flag-lərlə idarə olunur.

bashKopyala
# Çox qısa ömürlü branch (maksimum 1-2 gün)
git checkout -b small-fix/update-validation
# Kiçik dəyişiklik et, eyni gün merge et
git commit -m "fix: update email validation regex"
git push origin small-fix/update-validation
# PR aç, tez review al, merge et

Diqqət: Bu yanaşma güclü CI/CD pipeline və yaxşı test coverage tələb edir. Əgər komandanda test coverage 80%-dən aşağıdırsa, GitHub Flow ilə başla.

---

Commit Mesajları — Conventional Commits

Branch strategiyası qədər vacib olan bir şey də commit mesajlarıdır. Komandada standart olmalıdır:

feat: yeni funksionallıq
fix: bug düzəlişi
docs: dokumentasiya dəyişikliyi
style: format dəyişikliyi (kod məntiqi dəyişmir)
refactor: refaktoring
test: test əlavəsi
chore: build, CI/CD dəyişiklikləri

Pis nümunə:

bashKopyala
git commit -m "fix"
git commit -m "asdasd"
git commit -m "işləyir artıq"

Yaxşı nümunə:

bashKopyala
git commit -m "feat: add user registration with email verification"
git commit -m "fix: resolve null pointer exception in payment service"
git commit -m "docs: update API documentation for v2 endpoints"

---

PR Review Mədəniyyəti

Bakıda bir çox komandada müşahidə etdiyim problem: PR açılır, heç kim review etmir, 3 gün gözləyir, sonra review-suz merge olunur. Bu, branch strategiyasının bütün mənasını öldürür.

Praktiki qaydalar:

• PR maksimum 400 sətir olsun (daha çox olarsa, parçala)
• Review üçün maksimum 4 saat gözləmə limiti qoyun
• Minimum 1 approve tələb edin (GitLab/GitHub settings-dən)
• PR template istifadə edin:

markdownKopyala
## Nə dəyişdi?
- Payment service-ə yeni endpoint əlavə olundu

## Necə test etmək olar?
1. `POST /api/v1/payments` endpoint-inə request göndər
2. Response-da `transaction_id` olmalıdır

## Screenshot (əgər UI dəyişikliyi varsa)

---

Hansı Workflow-u Seçməliyəm?

Mənim tövsiyəm: Əgər Bakıda 2-8 nəfərlik komandada işləyirsənsə — ister aylıq 800 AZN maaşla junior olasan, istər 3000+ AZN alan senior — GitHub Flow ilə başla. Sadədir, effektivdir, öyrənməsi asandır. Komanda böyüdükcə Git Flow-ya keçə bilərsən.

---

Bonus: Branch Adlandırma Konvensiyası

Komandada razılaşın və bu formatı istifadə edin:

feature/JIRA-123-user-authentication
bugfix/JIRA-456-fix-login-redirect
hotfix/JIRA-789-critical-payment-bug
release/v2.1.0

JIRA, Linear və ya hansı project management tool istifadə edirsinizsə, ticket nömrəsini branch adına əlavə edin. Bu, traceability üçün əvəzsizdir.

---

Nəticə

Git workflow seçimi texniki qərar olduğu qədər də komanda mədəniyyəti qərarıdır. Ən yaxşı strategiya — komandanın razılaşdığı və ardıcıl tətbiq etdiyi strategiyadır.

Bu gün bir addım at: komandanla otur, bu məqaləni paylaş, workflow seçin və .github/PULL_REQUEST_TEMPLATE.md faylını repo-ya əlavə edin. Kiçik addım, böyük fərq.

Sualın varsa, şərhlərdə yaz — Baku Stack olaraq cavablandıracağıq! 🚀

Kod yazmaq fərdi bacarıqdır, kod idarə etmək isə komanda bacarığı.