Git-ийг зөв ашиглах нь

Ихэнх хүн Git-ийг гурван командаар л сурдаг: add, commit, push. Алдаа хэзээ орж ирснийг олох, андуурсан зүйлээ буцаах, эсвэл бусдын кодыг review хийх шаардлага гарах хүртэл энэ нь хангалттай байдаг. Тэгэхэд л Git хадгалах товч биш гэдгийг ойлгодог. Энэ бол түүх, тэр түүхийг хамгийн их уншдаг хүн нь зургаан сарын дараах та өөрөө юм.

Энэ нийтлэлд тэр түүхийг хэрэгтэй болгодог зуршлуудын тухай бичлээ.

Git хэрхэн ажилладаг вэ?

Таны өөрчлөлт гурван газрын аль нэгэнд байдаг:

flowchart LR
  A[Working tree<br/>засварлаж буй файлууд] -- git add --> B[Staging area<br/>дараагийн commit-д орох зүйлс]
  B -- git commit --> C[Түүх<br/>commit-ууд]
  C -- git push --> D[Remote<br/>GitHub, GitLab]

Working tree: таны диск дээрх файлууд.
Staging area (index гэж бас нэрлэдэг): дараагийн commit-д оруулахаар сонгосон өөрчлөлтүүд.
Түүх: commit-ууд. Commit бүр бол бүх төслийн агшин зуурын зураг (snapshot) бөгөөд өмнөх commit руугаа заасан холбоостой.

Branch гэдэг нь зүгээр л нэг commit руу заасан нэр. Branch үүсгэх нь маш хямд тул ажил бүрт тусдаа branch нээгээрэй.

Үүнийг ойлгочихвол ихэнх команд утгатай болно. git add өөрчлөлтийг staging руу оруулна. git restore --staged буцааж гаргана. git commit staging-ийг commit болгоно.

Commit хийхээсээ өмнө шалгах зүйлс

Хоёр командыг үргэлж ажиллуулж үзэх хэрэгтэй:

git status          # юу өөрчлөгдсөн, юу stage хийгдсэн
git diff --staged   # commit-д яг юу орох гэж байгаа

Ингэснээр мартсан debug console.log, санамсаргүй өөрчилсөн файл, заримдаа бүр .env файлыг ч барьж авна.

Жижиг commit хий

Нэг commit бол нэг логик өөрчлөлт: “огноо уншдаг алдааг засав”, харин “алдаа засав, хувьсагчдын нэр солив, dependency шинэчлэв, файлууд формат хийв” биш.

Жижиг commit-ыг review хийхэд, буцаахад, нэг жилийн дараа git log дээр олоод ойлгоход амархан.

Хэрэв аль хэдийн хоорондоо хамааралгүй хэд хэдэн зүйл өөрчилчихсөн бол бүгдийг нь хамт commit хийх албагүй. Файлын зөвхөн нэг хэсгийг stage хийж болно:

git add -p

Git өөрчлөлт бүрийг (“hunk”) харуулаад y (stage хийх), n (алгасах), s (жижиг хэсгүүдэд хуваах) гэж асууна. Энэ бол ихэнх эхлэгчдийн мэддэггүй, гэхдээ хамгийн хэрэгтэй Git команд.

Зөвлөгөө

Формат өөрчлөлт болон логик өөрчлөлтийг хэзээ ч нэг commit-д бүү хольж оруул. Formatter-ийн улмаас 300 мөр хөдөлсөн diff дотор жинхэнэ чухал 2 мөр нь далд орчихдог.

Ирээдүйн уншигчид зориулж мессеж бич

Юу өөрчлөгдсөнийг код өөрөө харуулчихна. Мессеж яагаад гэдгийг хэлэх ёстой.

Муу:

fix
update
changes
wip

Сайн:

Fix pubDate parsing for posts without timezone

Dates like '2026-10-08' were parsed as UTC midnight, so posts
showed the previous day in UTC-negative timezones. Parse them
as local dates instead.

Commit мессежийг ихэвчлэн англиар бичдэг. Түгээмэл формат нь:

Гарчиг мөр: 50 орчим тэмдэгт, тушаах хэлбэрээр (“Fixed”, “Fixes” биш “Fix”, “Add”, “Remove”). “Энэ commit-ыг хэрэгжүүлбэл fix pubDate parsing болно” гэж уншаад үзээрэй.
Хоосон мөр.
Их бие (заавал биш): өөрчлөлт яагаад хэрэгтэй байсан, ямар сонголт хийсэн, юу оролдоод бүтээгүй вэ.

Танай баг fix: ... / feat: ... гэх мэт дүрэм (Conventional Commits) ашигладаг байж болно. Тийм бол дагах хэрэгтэй. Учир нь дундын нэг адилхан бичэлт нь бусдад илүү ойлгомжтой болгодог.

Branch-аа богино байлга

Ажил бүрт нэг branch, хамгийн сүүлийн main-ээс үүсгэнэ:

git switch main
git pull
git switch -c fix-date-parsing

Branch удаан амьдрах тусам main түүнээс холдож, merge хийх нь төдий чинээ хэцүү болдог. Долоо хоног биш, хэдэн өдөр гэж бодоорой. Том feature байвал өөр өөрөө утгатай хэд хэдэн жижиг branch болгон хуваа.

main дээрх шинэ өөрчлөлтийг өөрийн branch руугаа оруулахын тулд merge эсвэл rebase хийж болно:

git fetch
git rebase origin/main   # commit-уудаа хамгийн сүүлийн main дээр дахин тавина
# эсвэл
git merge origin/main    # merge commit нэмнэ

Rebase илүү цэвэр, шулуун түүх үлдээдэг. Merge commit-уудыг хэзээ ч дахин бичдэггүй тул илүү аюулгүй. Багийнхаа ашигладгийг ашигла, гэхдээ эхлээд дараагийн хэсгийн дүрмийг ойлгоорой.

Хуваалцсан түүхийг хэзээ ч бүү дахин бич

rebase, commit --amend, reset зэрэг командууд шинэ commit үүсгэж, хуучныг нь хаядаг. Зөвхөн өөрийн local branch дээр бол асуудалгүй. Харин өөр хүн аль хэдийн pull хийсэн branch дээр ингэвэл тэдний хуулбарыг эвдэнэ.

Дүрэм: өөр хэн ч аваагүй зүйлийг л дахин бич.

Push хийсэн өөрийн branch-аа rebase хийгээд дахин push хийх хэрэгтэй бол:

git push --force-with-lease

--force биш. --force-with-lease нь таныг сүүлд fetch хийснээс хойш өөр хүн тэр branch руу push хийсэн бол push хийхээс татгалздаг. Ингэснээр бусдын ажлыг мэдэлгүй устгахаас сэргийлнэ.

Болгоомжил

main эсвэл хуваалцсан ямар ч branch руу хэзээ ч force push бүү хий.

Аюулгүй буцаах

Git-тэй холбоотой сандралын ихэнх нь яаж буцаахаа мэдэхгүйгээс үүсдэг. Товчхондоо:

Нөхцөл байдал	Команд
Файлыг unstage хийх (өөрчлөлт хэвээр үлдэнэ)	`git restore --staged <file>`
Файл дахь өөрчлөлтийг хаях	`git restore <file>`
Сүүлийн commit-ын мессежийг засах, мартсан файл нэмэх	`git commit --amend`
Сүүлийн commit-ыг буцаах, өөрчлөлтийг үлдээх	`git reset --soft HEAD~1`
Аль хэдийн push хийсэн commit-ыг буцаах	`git revert <commit>`

Хуваалцсан branch дээр git revert аюулгүй: хуучин commit-ыг буцаадаг шинэ commit үүсгэдэг тул түүх дахин бичигдэхгүй.

git restore <file> болон git reset --hard commit хийгээгүй ажлыг үнэхээр устгадаг. Commit хийгдээгүй байсан болохоор Git түүнийг сэргээж чадахгүй.

Хамгаалалтын тор: reflog

Commit хийсэн ажлаа алдах маш хэцүү. Буруу reset эсвэл rebase хийсний дараа ч Git HEAD хаана хаана байсныг санаж байдаг:

git reflog

HEAD@{3}: commit: Add tag pages гэх мэт жагсаалт харагдана. Хүссэн төлөвөө олоод тийшээ буцна:

git switch -c rescue HEAD@{3}

Reflog байдгийг мэдэхэд л Git-ээс айх айдас тань нэлээд багасна.

Түүхээ унш

Сайн түүх уншиж байж л хэрэгтэй. Цээжлэх хэрэгтэй хэдэн команд:

git log --oneline --graph           # commit, branch-уудыг товч харах
git log -p -- src/i18n.ts           # нэг файлын бүх өөрчлөлт, diff-тэйгээ
git log -S 'readingMinutes'         # энэ текстийг нэмсэн эсвэл хассан commit-ууд
git blame src/i18n.ts               # мөр бүрийг хэн, аль commit-д сүүлд өөрчилсөн
git show <commit>                   # нэг commit-ыг бүтнээр нь

git log -S нь “энэ функц хэзээ гарч ирсэн бэ?”, “энэ тохиргоог хэн устгасан бэ?” гэх мэт асуултад маш тохиромжтой. git blame танд commit өгнө, харин commit мессеж (найдвал) яагаад гэдгийг хэлнэ. Сайн commit мессеж яг энд л үр өгөөжөө өгдөг.

Нууц мэдээллийг оруулахгүй байх

Эхний өдрөөс .gitignore нэмж, дотор нь node_modules/, build-ийн гаралт, .env-г бич.

Хэрэв нууц мэдээлэл (API key, нууц үг, token) commit хийчихвэл:

Шууд солих (rotate). Шинэ түлхүүр үүсгээд хуучныг нь идэвхгүй болго.
Дараа нь хүсвэл түүхээс цэвэрлэ.

Шинэ commit-оор файлыг устгах нь тус болохгүй: нууц мэдээлэл хуучин commit дотор хэвээр байна. Нийтийн repo руу push хийгдсэн бол хэн нэгэн аль хэдийн хуулж авсан гэж үз. Жинхэнэ шийдэл нь зөвхөн солих.

Анхааруулга

git rm нь файлыг түүхээс биш, дараагийн commit-оос л хасдаг.

Товчхондоо

Commit бүрийн өмнө git status, git diff --staged ажиллуул.
Нэг commit, нэг логик өөрчлөлт. Хуваахдаа git add -p ашигла.
Commit мессеж: товч, тушаах хэлбэрийн гарчиг, их бие нь яагаад-ыг тайлбарлана.
Ажил бүрт нэг богино наслах branch.
Зөвхөн өөр хэн ч аваагүй түүхийг дахин бич. Энгийн --force биш, --force-with-lease ашигла.
Хуваалцсан branch дээр git revert, ямар нэг зүйл алдсан гэж бодвол git reflog.
Нууц мэдээлэл хэзээ ч commit бүү хий. Хийчихвэл эхлээд солих.