Skip to main content

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

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

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

Хяналт 8.32 — Өөрчлөлтийн менежмент (Change Management). Өөрчлөлт бүр MR-ээр дамжиж, MR бүрд өөрчлөлтийн төрлөөс хамааран Emergency change, Normal change, Standard change label-ийн нэгийг сонгосон байх ёстой. Энэ нь бүх project дээр заавал мөрдөгдөнө:

  • Project бүрд .gitlab/merge_request_templates/Default.md MR template байрлана (MR нээх бүрд шаардлагатай талбарууд + label сонгох сануулга автоматаар гарна).
  • Project бүрийн CI дээр check-change-label job (§4-ийн жишээ) label-ийн нэгийг сонгосон эсэхийг албадан шалгана — сонгоогүй бол pipeline унана.

CE limitation: pipeline амжилт нь merge-ийг албадан зогсоодоггүй тул (§10), label-check job нь "хатуу gate" биш харин анхааруулга. Хатуу албадлага хэрэгтэй бол §10-ийн protected-branch тохиргоо + pipeline-must-succeed-ийг асаа.

  • main = production. Үргэлж тогтвортой, release-д бэлэн. Шууд commit/push хийхгүй — зөвхөн staging-аас release-ээр орно.
  • staging = integration / QA branch. Feature-ууд энд нэгдэж, staging орчинд туршигдана.
  • Урсгал нэг чиглэлтэй: feature → staging → main (production).
  • Бүх өөрчлөлт MR-ээр дамжина. Богино настай branch нээж, MR-ээр нэгтгэнэ — шууд push байхгүй.
  • MR бүрд өөрчлөлтийн төрлийн label заавал сонгоно — өөрчлөлтийн шинжээс хамааран Emergency change, Normal change, Standard change-ийн нэгийг. Аль нь хэзээ болохыг §4-т үзэх.
  • Жижиг 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 гэх мэт.

  5. Өөрчлөлтийн төрөл (label) — MR-ийн баруун талын Labels-аас доорх гурвын нэгийг сонгоно. Template label-ийг сонгож өгдөггүй тул зохиогч өөрөө тавина.

    LabelХэзээ тавих
    Standard changeЭрсдэл багатай, давтагддаг ажил — chore/, docs/, dependency шинэчлэл.
    Normal changeТөлөвлөсөн feature, fix, refactor. Энгийн урсгал (§4–§7).
    Emergency changeProduction-ийн яаралтай засвар — §9-ийн hotfix урсгал.

    Label-ууд group level дээр тодорхойлогддог тул доорх project-ууд дээр өөрөө харагдана. Байхгүй бол Group → Manage → Labels дээр үүсгэнэ: Standard change #6699cc, Normal change #e6e6fa, Emergency change #dc143c.

Нэмэлт:

  • Гарчиг — 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>

<!-- ❗ Илгээхээсээ өмнө: баруун Sidebar → Labels-ээс "Standard change" /
     "Normal change" / "Emergency change" label-ийн нэгийг заавал сонго. -->

MR template тохируулах​

Загварыг MR бүрд гараар хуулах шаардлагагүй. .gitlab/merge_request_templates/Default.md файл нэмбэл GitLab MR нээх бүрд автоматаар description болгож ачаална:

mkdir -p .gitlab/merge_request_templates
$EDITOR .gitlab/merge_request_templates/Default.md   # дээрх загварыг хуулж тавь
git add .gitlab/merge_request_templates/Default.md
git commit -m "chore(mr): add default MR template"

  • Олон загвар хэрэгтэй бол Hotfix.md, Feature.md гэх мэтээр нэмнэ — MR нээхэд Choose a template dropdown-оос сонгоно. Default.md нь дандаа автоматаар ачаалагдана.

  • Settings → General → Merge requests дотроос бас загвар бичиж болно. Гэхдээ файлаар хийвэл version хяналтад орох тул файлыг зөвлөж байна.

  • Template нь зөвхөн description-ийг бөглөнө; label-ийг сонгож өгөхгүй (GitLab-д тэр боломж байхгүй). Тиймээс загварт сануулга comment тавьсан.

  • Label тавьсан эсэхийг албадан шалгуулмаар бол CI job нэмж болно:

    check-change-label:
      stage: .pre
      rules:
        - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
      script:
        - |
          echo "$CI_MERGE_REQUEST_LABELS" | grep -qE 'Standard change|Normal change|Emergency change' \
            || { echo "Standard / Normal / Emergency change label-ийн нэгийг тавина уу"; exit 1; }

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. Нэгтгэхийн хаалт​

Хоёр зүйлийг зааглаж ойлгоорой: GitLab-аар албадан хийж болох хаалт, ба зөвхөн багийн дэг хэвээр байгаа хаалт. Instance нь Community Edition тул хоёр дахь нь нэлээд байна.

GitLab-аар албадан хийж болох (CE дээр байгаа)​

Settings → Merge requests:

  • Pipelines must succeed — CI улаан бол нэгтгэхийг хориглоно. Lint, тест, build-ыг хаалт болгох гол тохиргоо нь энэ. (Одоо шалгасан 4 repo дээр бүгд унтраалттай.)
  • All threads must be resolved — шийдэгдээгүй сэтгэгдэлтэй MR нэгтгэхгүй.
  • Squash commits when merging: Require — squash-ийг дэг болгосон бол албадах хэрэгтэй. Одоо default_off байгаа тул бодит нэгтгэлүүд merge commit хэлбэрээр гарч байна.

Settings → Repository → Protected branches (main, staging тус бүрд):

  • Allowed to push and merge: No one — ингэснээр зөвхөн MR-ээр орно. Одоо Maintainer байгаа тул Maintainer шууд push хийж болж байна.
  • Allowed to merge: Developers + Maintainers, Allow force push: off.
  • kpi/backend дээр хамгаалагдсан branch бүртгэгдээгүй — эхлээд main-г хамгаалах шаардлагатай.

Зөвхөн багийн дэг (CE дээр албадаж болохгүй)​

  • Хамгийн багадаа 1 зөвшөөрөл. MR approval rule нь Premium боломж. CE дээр зөвшөөрлийн тоог албадах арга байхгүй — Reviewer-ээ томилж, approve-ыг хүлээж нэгтгэх нь багийн дэг.
  • Branch нь target-тайгаа шинэлэг байх. Merge train / auto-rebase нь Premium. CE дээр §6-ийн дагуу гараар rebase хийж шинэлэг байлгана.

Эдгээрийг албадмаар бол §4-т дурдсантай адил CI job бичиж шалгуулж болно (жишээ нь approve тоог API-аар шалгах job), эсвэл Premium лиценз авах шаардлагатай.

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-ийг хуучруулах