Skip to main content

SWR баг — Git ба Merge Request заавар

Branch загвар: GitLab/GitHub Flow · Шалгах түвшин: 1 зөвшөөрөл + ногоон CI · Нэгтгэх арга: Squash

1. Үндсэн зарчим​

  • main = production. Үргэлж тогтвортой, release-д бэлэн. Шууд commit/push байхгүй — зөвхөн staging-аас release-ээр орно.
  • staging = integration / QA branch. Feature-ууд энд нэгдэж, staging орчинд туршигдана.
  • Урсгал нэг чиглэлтэй: feature → staging → main (production).
  • Бүх өөрчлөлт богино настай branch болон Merge Request (MR)-ээр дамжина.
  • Жижиг MR хурдан нэгдэж, сайн хянагдана. Зорилго: ~400 мөрөөс бага зөрүү.
  • Нэг MR = нэг логик өөрчлөлт. Хоорондоо хамааралгүй ажлыг нэг дор бүү багцал.

2. Branch үүсгэх (Branching)​

Хамгийн сүүлийн staging-аас branch үүсгэнэ (integration branch):

git checkout staging
git pull origin staging
git checkout -b feat/checkout-coupon

Нэрлэх дүрэм: <type>/<short-description>

ТөрөлХэрэглээ
feat/шинэ боломж (feature)
fix/алдаа засвар
refactor/бүтэц өөрчлөх, үйлдэл өөрчлөгдөхгүй
chore/хэрэгсэл, dependency, тохиргоо
docs/зөвхөн баримт бичиг
hotfix/production дээрх яаралтай засвар

Branch богино настай байлга — MR-ийг 1–2 хоногийн дотор нээж, хэдхэн хоногт нэгтгэ. Удаан амьдарсан branch хазайж муудна.

3. Commit-ууд​

MR гарчигт Conventional Commits хэлбэрийг ашигла (энэ нь staging дээрх squash хийгдсэн commit болно):

feat(checkout): apply coupon code at payment step
fix(auth): refresh token before expiry
  • Гарчиг ≤ 50 тэмдэгт, тушаах хэлбэрээр ("add", "added" биш).
  • Тайлбар хэсэгт юу биш яагаад гэдгийг бич — юу хийсэн нь зөрүүнд аль хэдийн харагдана.
  • Branch дээрээ олон удаа commit хий; замбараагүй байсан ч хамаагүй — squash цэвэрлэнэ.

4. Merge Request нээх​

Push хийгээд MR-ийг эрт нээ (бэлэн биш бол Draft гэж тэмдэглэ):

git push -u origin feat/checkout-coupon

Target branch: staging (main биш). Feature-ууд эхлээд staging руу орж туршигдана.

MR-д дараах мэдээлэл заавал тусгагдсан байна:

  1. Өөрчлөлтийн зорилго, тайлбар — юуг, яагаад өөрчилсөн.
  2. Туршилтын үр дүн — ямар тест хийсэн, үр дүн (бүх CI ногоон + гар аргаар шалгасан алхмууд).
  3. Rollback шаардлага — буцаах боломжтой эсэх, буцаах алхмууд, өгөгдөл/миграцид үзүүлэх нөлөө.
  4. Холбогдох ticket, issue, task-ийн холбоос — Closes #123 гэх мэт.

Нэмэлт:

  • Гарчиг — Conventional Commit хэлбэр (эцсийн commit мессеж энэ болно).
  • Дэлгэцийн зураг / бичлэг — UI-д өөрчлөлт орсон бол.
  • Өөрийгөө хянах — review хүсэхээсээ өмнө өөрийн зөрүүг уншиж шалга.

MR тайлбарын загвар:

## Зорилго, тайлбар (Purpose)
Юуг, яагаад өөрчилсөн. Асуудал / нөхцөл.

## Туршилтын үр дүн (Test results)
- [ ] Unit / integration тест ногоон
- [ ] Гар аргаар шалгасан: <алхмууд ба үр дүн>

## Rollback шаардлага (Rollback)
- Буцаах боломжтой эсэх: Тийм / Үгүй
- Буцаах алхам: <revert, migration буцаах, feature flag унтраах гэх мэт>
- Эрсдэл / нөлөө: <өгөгдөл, миграц, хамаарал>

## Холбогдох ticket / issue / task (Links)
Closes #___, холбоос: <ticket/issue/task URL>

5. Хяналт ба зөвшөөрөл​

Нэгтгэх босго: 1 зөвшөөрөл + бүх CI шалгалт ногоон.

Зохиогч (Author):

  • MR-ийг жижиг, төвлөрсөн байлга.
  • Бүх сэтгэгдэлд хариул (шийдвэрлэ, эсвэл яагаад шийдээгүйгээ тайлбарла).
  • Өөрчлөлт push хийсний дараа дахин review хүс.

Хянагч (Reviewer):

  • ~1 ажлын өдрийн дотор хяна. Багийнхаа ажлыг түгжрэлээс гаргах нь өөрийн гүнзгий ажлаас чухал.
  • Шалгах зүйл: зөв эсэх, ирмэгийн тохиолдол (edge case), тест, уншигдах байдал, аюулгүй байдал.
  • Тодорхой бөгөөд эелдэг бай. Тушаахын оронд санал болго. Блоклохгүй зүйлд nit: ашигла.
  • Сайн бол зөвшөөр — хувийн загварын дуршилаар бүү саатуул.

Хэлэлцүүлэг шийдвэрлэх: засагдсаны дараа зохиогч thread-ийг хаана; сэтгэл хангалуун бус бол хянагч дахин нээнэ.

6. Branch-ийг шинэлэг байлгах​

staging дээр rebase хийж шинэлэг, цэвэр түүхтэй байлга:

git fetch origin
git rebase origin/staging
# зөрчлийг шийдээд:
git push --force-with-lease

Үргэлж --force-with-lease ашигла (хэзээ ч энгийн --force биш) — энэ нь чиний хараагүй ажлыг дарж бичихээс татгалзана.

7. Нэгтгэх (Merging)​

  • Арга: Squash merge. Feature branch staging дээр нэг commit болж нийлж, MR гарчгаар нэрлэгдэнэ.
  • Зөвхөн дараах үед нэгтгэ: 1 зөвшөөрөл ✅ + CI ногоон ✅ + thread-ууд шийдэгдсэн ✅ + Rollback хэсэг бөглөгдсөн ✅.
  • Зохиогч нэгтгэнэ (бэлэн эсэхийг тэр мэднэ), баг өөрөөр тохиролцоогүй бол.
  • Нэгтгэсний дараа branch-ийг устга (auto-delete-ийг асаа).
  • staging нь CD pipeline-ийн дагуу staging орчинд дахин deploy хийгдэж, QA шалгана.

8. Орчны урсгал — staging ба production​

Зөвхөн хоёр орчны branch: staging (QA) ба main (production). Production-ийн тусдаа branch байхгүй — main нь өөрөө production.

BranchОрчинХэзээ deploy
stagingstaging (QA)feature MR нэгтгэх бүрт
mainproductionstaging → main release нэгтгэхэд

Урсгал:

  1. feature → MR → staging (squash). staging орчинд deploy → QA шалгана.
  2. staging дээр баталгаажсаны дараа release: staging → main MR нээж нэгтгэнэ → production deploy.
  3. Release бүрт main дээр tag тавина.
# Release: staging → main (production)
git checkout main && git pull
git merge --no-ff origin/staging     # эсвэл GitLab дээр MR-ээр (зөвлөмж)
git tag -a v1.4.0 -m "release v1.4.0"
git push origin main --tags

Дүрэм:

  • Кодыг зөвхөн дээш урсга (feature → staging → main). main руу шууд feature нэгтгэж болохгүй — зөвхөн staging-аас release-ээр орно.
  • Release нэгтгэлд (staging → main) merge commit (--no-ff) ашигла — squash биш. Ингэснээр аль commit production-д очсон түүх хадгалагдана.
  • staging, main-г protected branch болго: шууд push байхгүй, MR заавал, 1 зөвшөөрөл.
  • production (main) руу нэгтгэх бүрт release tag (v1.4.0) тавь.

9. Hotfix (яаралтай засвар)​

Production дээрх яаралтай алдааг засахдаа staging-ийг тойрч, main-аас шууд салаална:

git checkout -b hotfix/payment-timeout main
# зас, push, MR нээ → main
  • Мөн адил CI ногоон + 1 зөвшөөрөл шаардлагатай (боломжтой хэн нэгнийг ав).
  • main руу нэгтгэ, deploy хий, production дээр баталгаажуул, release tag тавь.
  • Чухал: засварыг алдахгүйн тулд main-г буцааж staging руу нэгтгэ — эс бөгөөс дараагийн release дээр алга болно.

10. CI хаалт (нэгтгэхээс өмнө заавал)​

staging ба main дээр branch protection тохируулж, эдгээрийг нэгтгэхийг блоклодог болго:

  • ✅ Lint / format
  • ✅ Unit + integration тест
  • ✅ Build
  • ✅ Хамгийн багадаа 1 зөвшөөрөл
  • ✅ Branch нь target-тайгаа (staging/main) шинэлэг (up to date)

staging, main-г хамгаал: шууд push байхгүй, force-push байхгүй, MR заавал.

11. Хурдан лавлах​

# эхлэх (staging-аас)
git checkout staging && git pull
git checkout -b feat/thing

# ажиллах
git add -p && git commit -m "wip"

# шинэлэг байлгах
git fetch origin && git rebase origin/staging
git push --force-with-lease

# нэгтгэх (target = staging)
git push -u origin feat/thing      # MR → staging → review → squash merge → branch устга

# release (staging → main = production)
git checkout main && git merge --no-ff origin/staging
git tag -a v1.4.0 -m "release v1.4.0" && git push origin main --tags

Хийх (Do)

  • Жижиг, төвлөрсөн MR · тодорхой гарчиг · хурдан review · --force-with-lease

Бүү хий (Don't)

  • main-д push · хамааралгүй өөрчлөлт багцлах · улаан CI нэгтгэх · энгийн git push --force · branch-ийг хуучруулах