၅ · ကွန်ရက် အင်ဂျင်နီယာများအတွက် Git (Git for Network Engineers)¶

Configuration သည် Code သာ ဖြစ်ပါသည်။ ထိုအချက်ကို သင် လက်ခံလိုက်သည်နှင့်တစ်ပြိုင်နက် Change Management ဆိုင်ရာ မေးခွန်းတိုင်းအတွက် အဖြေအသင့် ရှိပြီးသား ဖြစ်သွားပါမည်။

Automation မစတင်မီ Git ကို မဖြစ်မနေ တတ်မြောက်ထားရပါမည် — Ansible playbooks၊ Python scripts များနှင့် CI pipelines များအားလုံးသည် Git အတွင်း၌သာ တည်ရှိနေကြသောကြောင့် ဖြစ်သည်။

Git က သင့်အား မည်သည့်အရာများ ပေးစွမ်းသနည်း¶

မေးခွန်း	Git မသုံးပါက	Git သုံးထားပါက
မနေ့ညက မည်သည့်အရာ ပြောင်းသွားသနည်း	Backup ဖိုင်များကို လက်ဖြင့် နှိုင်းယှဉ်ရသည်	`git diff HEAD~1`
မည်သူက အဘယ်ကြောင့် ပြင်ဆင်ခဲ့သနည်း	လိုက်လံမေးမြန်းရသည်	`git log -p` / `git blame`
အဆိုပါ ပြောင်းလဲမှုကို နောက်ပြန်ဆုတ် (Rollback) ရန်	ဖိုင်အဟောင်းကို ရှာဖွေပြီး မှန်ကန်ရန် မျှော်လင့်ရသည်	`git revert`
အန္တရာယ်များသော အရာတစ်ခု စမ်းသပ်ရန်	Folder တစ်ခုလုံးကို copy ကူးရသည်	`git checkout -b`
စက်ပေါ်မတင်မီ အတည်ပြု စစ်ဆေးရန်	Diff ကို အီးမေးလ် ပို့ရသည်	Pull Request (PR)

နောက်ဆုံးစာကြောင်းသည် အဓိက အကျိုးကျေးဇူး ဖြစ်ပါသည်: ပြောင်းလဲမှုများကို စက်များပေါ်သို့ မရောက်မီ ကြိုတင် သုံးသပ်အတည်ပြုနိုင်သည်၊ ထို့အပြင် စစ်ဆေးမှုတွင် အတိအကျ ပြင်ဆင်ထားသော diff ပါဝင်နေပါသည်။

Git ၏ လုပ်ဆောင်မှု ပုံစံ (The Model)¶

ပြောင်းလဲမှုတစ်ခု တည်ရှိနိုင်သော နေရာ ၃ ခု:

graph LR
    A["Working tree<br/>မိမိပြင်ဆင်ထားမှုများ"] -->|"git add"| B["Staging area<br/>Commit လုပ်ရန် အသင့်"]
    B -->|"git commit"| C["Repository<br/>အမြဲတမ်း မှတ်တမ်း"]
    C -->|"git push"| D["Remote<br/>ဗဟိုဆာဗာ"]
    classDef s fill:#1565c0,stroke:#90caf9,color:#ffffff,stroke-width:2px,font-size:14px;
    classDef r fill:#2e7d32,stroke:#a5d6a7,color:#ffffff,stroke-width:2px,font-size:14px;
    class A,B,C s; class D r;

Staging Area (Index) သည် အစပြုသူများကို ရှုပ်ထွေးစေတတ်သော နေရာဖြစ်သည်။ ၎င်းသည် ပြောင်းလဲမှုအားလုံးထဲမှ အချို့ကိုသာ ခွဲထုတ် commit ပြုလုပ်နိုင်ရန် တည်ရှိခြင်း ဖြစ်သည် — ဥပမာ စာလုံးပေါင်းအမှားတစ်ခု ပြင်ဆင်ခြင်းနှင့် BGP policy ပြောင်းလဲခြင်းတို့ကို တစ်ပြိုင်နက် လုပ်ဆောင်ခဲ့ပါက ၎င်းတို့ကို သီးခြားစီ commit လုပ်ပြီး ရှင်းလင်းသော message ရေးသားနိုင်ပါသည်။

နေ့စဉ်သုံး Commands များ¶

git status                  # မည်သည့်အရာများ ပြောင်းလဲနေသည်ကို ကြည့်သည် — အမြဲ စစ်ဆေးပါ
git diff                    # Stage မလုပ်ရသေးသော ပြောင်းလဲမှုများ
git diff --staged           # Commit ပြုလုပ်တော့မည့် ပြောင်းလဲမှုများ
git add configs/r1.cfg      # ဖိုင်တစ်ခုကို stage လုပ်သည်
git add -p                  # ဖိုင်အတွင်းမှ အပိုင်းအစများကို ရွေးချယ် stage လုပ်သည် — အလွန်အသုံးဝင်သည်
git commit -m "message"
git log --oneline -10
git push

git add -p သည် ပြင်ဆင်မှုတစ်ခုချင်းစီကို လိုက်လံပြသပြီး stage လုပ်မလုပ် မေးမြန်းပေးပါသည်။ Commit မလုပ်မီ မိမိအလုပ်ကို မိမိကိုယ်တိုင် ပြန်လည်စစ်ဆေးရန် အကောင်းဆုံး နည်းလမ်း ဖြစ်သည်။

Config Backups များကို Git ဖြင့် စီမံခြင်း¶

#!/usr/bin/env bash
set -euo pipefail
cd /opt/network-configs

for n in r1 r2 r3; do
  docker exec "clab-bgp-lab-$n" Cli -p 15 -c "show running-config" \
    | sed -e '/^! device:/d' -e '/Last configuration change/d' \
    > "configs/$n.cfg"
done

if ! git diff --quiet; then
  git add configs/
  git commit -m "config snapshot $(date -Iseconds)"
  git push
fi

အလုပ်ဖြစ်စေသော အဓိက အချက် ၂ ချက်:

ပြောင်းလဲလွယ်သော စာကြောင်းများကို ဖယ်ရှားပါ။ Timestamps များနှင့် uptime ကောင်တာများသည် poll လုပ်တိုင်း ပြောင်းလဲနေသည်။ sed မပါပါက အကြိမ်တိုင်း diff ထွက်ပေါ်နေပြီး နောက်ဆုံးတွင် မည်သူမျှ မဖတ်ရှုတော့ဘဲ ဖြစ်သွားပါမည်။

Commit မလုပ်မီ git diff --quiet ဖြင့် စစ်ဆေးပါ။ Exit code 0 ဆိုသည်မှာ မည်သည့်အရာမျှ မပြောင်းလဲဟု အဓိပ္ပာယ်ရသဖြင့် commit ပြုလုပ်ခြင်းကို ကျော်သွားစေသည်။ သို့မဟုတ်ပါက ၅ မိနစ်တစ်ကြိမ် ဗလာ commit များ တက်လာပြီး history မှတ်တမ်း ပျက်စီးသွားပါလိမ့်မည်။

၎င်းကို cron ဖြင့် run ထားပါက အပြည့်အစုံသော history နှင့် blame ပါဝင်သည့် အလိုအလျောက် config tracking စနစ် ရရှိမည် ဖြစ်သည်။

History မှတ်တမ်းများကို ဖတ်ရှုခြင်း¶

git log --oneline --graph --all      # မြေပုံပုံစံဖြင့် visual history ကြည့်သည်
git log -p configs/r1.cfg            # ဖိုင်တစ်ခုတည်း၏ ပြောင်းလဲမှုအားလုံးကို diffs များနှင့်တကွ ပြသည်
git log --since="1 week ago"
git blame configs/r1.cfg             # လိုင်းတစ်ခုချင်းစီကို မည်သူ နောက်ဆုံးပြင်ဆင်ခဲ့သည်ကို ကြည့်သည်
git show <commit>                    # Commit တစ်ခုလုံး၏ အသေးစိတ်

git diff HEAD~1                      # နောက်ဆုံး commit နှင့် နှိုင်းယှဉ်သည်
git diff main..feature               # Branches နှစ်ခုအကြား နှိုင်းယှဉ်သည်
git diff --stat                      # မည်သည့်ဖိုင်များ ပြောင်းလဲသွားသည်ကို အကျဉ်းချုပ် ပြသည်

Config ဖိုင်တစ်ခုပေါ်တွင် git blame စစ်ဆေးခြင်းသည် "ဤစာကြောင်း အဘယ်ကြောင့် ဤနေရာသို့ ရောက်နေသနည်း" ကို ချက်ချင်း အဖြေပေးနိုင်ပါသည် — ထိုသူ ထွက်သွားပြီးနောက် အခြားနည်းဖြင့် မည်သို့မျှ ရှာမရနိုင်သော အချက်အလက် ဖြစ်သည်။

Branches (ခွဲဖြာမှုများ)¶

git checkout -b add-bgp-community    # Branch အသစ်ဖွင့်ပြီး ကူးပြောင်းသည်
git checkout main                    # Main branch သို့ ပြန်ကူးသည်
git merge add-bgp-community
git branch -d add-bgp-community      # ပေါင်းစည်းပြီးပါက ပြန်ဖျက်သည်

ကွန်ရက်လုပ်ငန်းများအတွက် အကောင်းဆုံး pattern မှာ ပြောင်းလဲမှုတစ်ခုလျှင် branch တစ်ခု ဖွင့်ခြင်း ဖြစ်သည်: တည်ဆောက်သည်၊ diff ကို စစ်ဆေးသည်၊ အတည်ပြုပြီးပါက merge လုပ်သည်။ Branch ကိုယ်တိုင်သည် Change Request တစ်ခု ဖြစ်လာပါသည်။

အမှားများကို ပြန်လည်ပြင်ဆင်ခြင်း (Undoing Things)¶

ဖိအားများအောက်တွင် လူအများ မှားယွင်းတတ်သော commands များ — သေချာစွာ မှတ်သားထားပါ:

အခြေအနေ	Command	ဘေးကင်းမှု
Stage လုပ်ထားသောဖိုင်ကို ပြန်ထုတ်ရန်	`git restore --staged <file>`	✅ ဘေးကင်းသည်
Local ပြင်ဆင်မှုများကို ဖျက်ပစ်ရန်	`git restore <file>`	⚠️ ပြင်ဆင်မှုများ ဆုံးရှုံးမည်
နောက်ဆုံး Commit message ကို ပြင်ရန်	`git commit --amend`	⚠️ Push မလုပ်ရသေးမှသာ
Push ပြီးသား Commit ကို ပြန်ဖျက်ရန်	`git revert <commit>`	✅ အလုံခြုံဆုံး နည်းလမ်း
Branch ကို နောက်သို့ အတင်းရွှေ့ရန်	`git reset --hard <commit>`	❌ လုပ်လက်စများ ပျက်စီးမည်

အခြားသူများနှင့် မျှဝေသုံးစွဲနေသော နေရာများတွင် reset မသုံးဘဲ revert ကိုသာ သုံးပါ

git revert သည် မူလ commit ကို ဖျက်ပယ်သော အသစ် commit တစ်ခု ကို တည်ဆောက်ပေးပါသည်။ History မှတ်တမ်း မပျက်စီးဘဲ အခြားသူများ၏ clone နှင့် တစ်ပြေးညီ ဆက်လက် ရှိနေစေပါသည်။

git reset --hard သည် history ကို ပြန်လည်ပြင်ရေးခြင်း ဖြစ်သည်။ ၎င်းသည် အခြားသူများ၏ repo များကို ပျက်စီးစေပြီး ပယ်ဖျက်လိုက်သော commits များကို ပြန်လည်ရယူရန် အလွန်ခက်ခဲပါသည်။

.gitignore ဖိုင်¶

Credentials (Passwords/Keys) များကို ဘယ်တော့မှ Commit မလုပ်ပါနှင့်။ တစ်ကြိမ် push မိသွားပါက လုံခြုံရေးကျိုးပေါက်သွားပြီဟု ယူဆရမည် — နောက်မှ ဖျက်ပစ်သော်လည်း git history ထဲတွင် ကျန်ရစ်နေမည် ဖြစ်သည်။

# .gitignore
*.key
*.pem
secrets.yml
.env
inventory/passwords.yml
__pycache__/
.venv/

Repo နှင့်အတူ သိမ်းဆည်းရမည့် လျှို့ဝှက်ချက်များအတွက် ansible-vault သို့မဟုတ် Secrets Manager ကိုသာ အသုံးပြုပါ။

အထောက်အကူပြုသော Commit Messages များ ရေးသားခြင်း¶

တစ်နှစ်ခန့် ကြာပြီးနောက် git log သည် အဘယ်ကြောင့် ပြင်ခဲ့သည် ကို သိရှိနိုင်မည့် တစ်ခုတည်းသော မှတ်တမ်း ဖြစ်လာပါမည်:

✗ update config
✗ fix
✗ changes

✓ r1: set next-hop-self on iBGP peer to 2.2.2.2
✓ Fixes routes resolving via management interface instead of Ethernet1.
✓ Symptom was a valid-looking BGP route with an unreachable next hop.

ပထမစာကြောင်းကို တိုတိုနှင့် တိကျစွာ ရေးပါ။ အကယ်၍ ပြောင်းလဲရသည့် အကြောင်းရင်း မထင်ရှားပါက အဘယ်ကြောင့် (Why) ပြင်ဆင်ခဲ့သည်ကို ရှင်းပြပါ — diff က ဘာပြင်ခဲ့သည် (What) ကို ပြသပြီးသား ဖြစ်သည်။

အင်တာဗျူးများတွင် မေးလေ့ရှိသော ပုံစံများ¶

Automation နှင့် သက်ဆိုင်သော အင်တာဗျူးတိုင်းတွင် Git နှင့်ပတ်သက်၍ မေးလေ့ရှိပါသည်:

"Configuration အပြောင်းအလဲများကို မည်သို့ ခြေရာခံသနည်း" — Config များကို Git တွင် သိမ်းသည်၊ အလိုအလျောက် snapshots ရယူပြီး diffs များကို စစ်ဆေးသည်။
"မှားယွင်းသော အပြောင်းအလဲတစ်ခုကို မည်သို့ Rollback လုပ်မည်နည်း" — git revert ကို သုံးပြီး reset ကို အဘယ်ကြောင့် မသုံးသင့်ကြောင်း ရှင်းပြပါ။
"ကွန်ရက် အပြောင်းအလဲများကို မည်သို့ စစ်ဆေးအတည်ပြုသနည်း" — Branch ခွဲသည်၊ Pull Request တင်သည်၊ Diff ကို ပူးတွဲစစ်ဆေးသည်။
"စက် Passwords/Keys များကို မည်သည့်နေရာတွင် ထားရှိသနည်း" — Repo ထဲ လုံးဝ မထားပါ; Vault သို့မဟုတ် Secrets Manager တွင်သာ ထားရှိသည်။

ဆက်လက်လေ့လာရန်: Linux Kernel Networking →