Thuta Learning
Git & GitHub: Collaboration and Professional Workflows
ExercisesDevOps & Toolsintermediate

လေ့ကျင့်ခန်း — AI Coding Agent များနှင့် Git ကို ဘေးကင်းစွာ အသုံးပြုခြင်း

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • လေ့ကျင့်ခန်း — AI Coding Agent များနှင့် Git ကို ဘေးကင်းစွာ အသုံးပြုခြင်း concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး Git/GitHub workflow ထဲမှာ state (သို့) data ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project/team အတွက် ဘယ်လို အသုံးချသင့်သလဲ ဆုံးဖြတ်နိုင်ရန်

နားလည်ထားရမယ့် အချက်

AI coding agent တစ်ခုက စက္ကန့်သုံးဆယ်အတွင်း ဂရုတစိုက် developer တစ်ယောက် တစ်နာရီကြာမယ့်အလုပ်ကို ထုတ်လုပ်နိုင်ပါတယ် — file ငါးခုကျော်မှာ feature အသစ်, controller တိုင်းကို ထိသွားတဲ့ refactor, dependency bump တစ်ခုနဲ့ လိုအပ်တဲ့ code change တွေ။ ဒီမြန်နှုန်းက တကယ်ကို အသုံးဝင်ပေမယ့်, ဒါကြောင့်ပဲ ဒီနေရာမှာ Git က ပိုအရေးကြီးလာတာပါ, ပိုမလိုအပ်တာမဟုတ်ပါဘူး။

Code ကို ဖြည်းဖြည်းရေးတဲ့ လူသားတစ်ယောက်က လုပ်ရင်းနဲ့ တစ်ကြောင်းချင်း self-review လုပ်တတ်ပါတယ်။ Agent တစ်ခုကတော့ file တစ်ခုနဲ့တစ်ခုကြား ရပ်တန့်ခြင်းမရှိပါဘူး, ပြီးတော့ change အမှန်တကယ် မှန်ကန်မှန်ကန် ဂရုမစိုက်ပါဘူး — plausible diff ထုတ်လုပ်ဖို့ optimize လုပ်တာပါ, ဒီ diff ဖြစ်သင့်မဖြစ်သင့် ဆုံးဖြတ်ချက်အတွက် မဟုတ်ပါဘူး။

  • Agent မစခင် known-good checkpoint commit တစ်ခု။
  • ဘာမှမယုံခင် `git diff` review အပြည့်အစုံ။
  • ရလဒ်မှားနေရင် ပြန်ချိန်ညှိနိုင်တဲ့ သန့်ရှင်းတဲ့လမ်း (restore, reset, revert)။

"Agent က file အများကြီးပြောင်းလိုက်ပြီ" ဆိုတဲ့အရာကို ယုံကြည်ရုံနဲ့ လက်ခံရမယ့် အခြေအနေကနေ တကယ်စစ်ဆေးနိုင်, လိုအပ်ရင် ပြန်ဖျက်နိုင်တဲ့ အရာအဖြစ် ပြောင်းပေးတာက Git ပါ။ ဒါက ထူးဆန်းတဲ့အရာမဟုတ်ပါဘူး — ရှိပြီးသား command တွေပဲဖြစ်ပြီး စည်းမျဉ်းတစ်ခုသာ ထပ်ဖြည့်ထားတာပါ — agent က code ကို မြန်မြန်ရေးလိုက်လို့ review step ကို ဘယ်တော့မှ မကျော်ရပါ။

Agent ကို destructive Git command များ ကြီးကြပ်မှုမရှိဘဲ run ခွင့်မပေးပါနှင့်

AI agent တစ်ခုကို force-push, hard reset, history ပြန်ရေးခြင်း လို destructive Git operation များကို ပုံမှန်အားဖြင့် ကန့်သတ်ချက်မရှိ, review မလုပ်ဘဲ ခွင့်ပြုသင့်ပါဘူး။ Agent ဖန်တီးတဲ့ diff တိုင်းကို သူစိမ်းတစ်ယောက်ရဲ့ pull request လို ဆက်ဆံပါ — မယုံခင် ဖတ်ပါ, checkpoint commit ကို ကန့်သတ်ချက်မရှိ ပြန်ချိန်ညှိနိုင်တဲ့လမ်းအဖြစ် ထားပါ။

text
THE AGENT-EDIT REVIEW LOOP
--------------------------
STEP 1  commit a clean checkpoint (safe point to return to)
   |
   v
STEP 2  AI agent edits code (often touches several files fast)
   |
   v
STEP 3  git diff -- read every changed line before anything else
   |
   v
STEP 4  run lint + tests
   |
   v
STEP 5  extra scrutiny: auth, secrets, permissions, dependencies
   |
   +-------------------------------+
   |                                |
 change is GOOD                 change is BAD
   |                                |
   v                                v
 git add + commit             git restore / reset / revert
 (describe what changed)      (back to the checkpoint)
   |                                |
   +---------------+----------------+
                   |
                   v
         repeat for the next agent task

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Git repository အစစ်တစ်ခုထဲမှာ simulate လုပ်ထားတဲ့ agent task နှစ်ပတ်ကို ဖြတ်သန်းပါမယ်။ Checkpoint commit တစ်ခုက known-good state ကို ချုပ်ကိုင်ထားပါတယ် — agent မထိခင် test အောင်ပြီးသား `calc.py` module ငယ်လေးတစ်ခု။ အကြံပြုထားတဲ့ workflow အစီအစဉ်အတိုင်း —

Checkpoint Commit လုပ်ပါ

Agent ကို task မပေးခင် သန့်ရှင်းသော known-good state ကို commit လုပ်ပါ။ ဒါက အမြဲပြန်ရောက်နိုင်တဲ့ နေရာပါ။

Agent ကို Edit ခိုင်းပါ

Task ကို လွှဲပေးပါ။ Agent က တစ်ကြိမ်တည်းမှာ file အများကြီးကို ထိနိုင်ပါတယ်။

Diff ကို Review လုပ်ပါ

ဘာမှမလုပ်ခင် `git diff` run ပြီး ပြောင်းလဲတဲ့ line တိုင်းကို ဖတ်ပါ။ Plausible ဖြစ်တယ်ဆိုပြီး agent ရေးထားတဲ့ code ကို မှန်ကန်တယ်လို့ ဘယ်တော့မှ မယူဆပါနှင့်။

Lint နှင့် Test များ Run ပါ

လူတစ်ယောက်ရေးထားတဲ့ pull request အတွက် လုပ်သလိုပဲ change ပေါ် project ရဲ့ lint နှင့် test suite ကို run ပါ။

Security-sensitive File များကို အသေးစိတ် စစ်ဆေးပါ

Auth, secret, permission, (သို့) dependency ထိသွားတဲ့ file တိုင်းကို အထူးအာရုံစိုက်ပါ — အန္တရာယ်ရှိတဲ့ change လေးတွေ ပုန်းအောင်းနိုင်တဲ့ တိကျသော နေရာပါ။

Commit လုပ် (သို့) ပြန်ဆုတ်ပါ

Change ကောင်းရင် `git add` ပြီး တကယ့်ရှင်းလင်းချက်နဲ့ `git commit` လုပ်ပါ။ မကောင်းရင် ပြဿနာကို ကိုယ်တိုင်ပြင်ဆင်နေမယ့်အစား `git restore`, `git reset`, (သို့) `git revert` နဲ့ checkpoint ကို ပြန်သွားပါ။

ပထမပတ်မှာ, simulate လုပ်ထားတဲ့ agent edit က helper function အစစ်တစ်ခု ထည့်ပြီး config file ထဲမှာ API key ကိုပါ hardcode ထည့်ပါတယ် — diff review က ဖမ်းမိပြီး, change တစ်ခုလုံးကို `git restore` နဲ့ ပယ်ချပါတယ်။ ဒုတိယပတ်မှာ, scope ကောင်းကောင်းရှိတဲ့ function-and-test change ကို review, test, ပြီးမှ အစစ်အမှန် commit လုပ်ပါတယ်။ Command တွေက နှစ်ခါစလုံး တူညီပါတယ်; ကွဲပြားတာက ဆုံးဖြတ်ခင် ကြည့်ခဲ့သလား ဆိုတာချည်းပါပဲ။

Agent ကို destructive Git command များ ကြီးကြပ်မှုမရှိဘဲ run ခွင့်မပေးပါနှင့်

Agent ဖန်တီးထားတဲ့ code ကို မျက်စိမှိတ်ပြီး ဘယ်တော့မှ commit မလုပ်ရပါ, AI agent ကို force-push, hard reset, history ပြန်ရေးခြင်းလို destructive Git operation များကို ပုံမှန်အားဖြင့် ကန့်သတ်ချက်မရှိ, review မလုပ်ဘဲ ခွင့်ပြုသင့်ပါဘူး။ Checkpoint commit နှင့် diff review တို့သည် ရွေးချယ်စရာ ထပ်ဆောင်းအရာများ မဟုတ်ပါ — agent ကို မြန်မြန်ဆန်ဆန် ဘေးကင်းစွာ အသုံးပြုနိုင်စေတာက ဒါတွေပါပဲ။

အတူတူ စမ်းရေးကြည့်မယ်

bash
# One-time setup (once per machine)
git config --global init.defaultBranch main

mkdir project && cd project
git init

# calc.py -- the module the agent will be asked to extend
cat > calc.py <<'EOF'
def add(a, b):
    return a + b
EOF

# test_calc.py -- a passing test for the current code
cat > test_calc.py <<'EOF'
from calc import add


def test_add():
    assert add(2, 3) == 5
EOF

# config.py -- a normal, non-secret config module
cat > config.py <<'EOF'
import os

DATABASE_URL = os.environ.get("DATABASE_URL", "postgres://localhost/myapp_dev")
DEBUG = True
EOF

export GIT_AUTHOR_NAME="Thuta Learner"
export GIT_AUTHOR_EMAIL="learner@example.com"
export GIT_COMMITTER_NAME="Thuta Learner"
export GIT_COMMITTER_EMAIL="learner@example.com"
export GIT_AUTHOR_DATE="2026-02-01T09:00:00"
export GIT_COMMITTER_DATE="2026-02-01T09:00:00"

git add calc.py test_calc.py config.py
git commit -m "Checkpoint: add() function, tests, and config pass before starting agent task"

# ======================================================================
# ROUND 1 -- a BAD agent edit: a real helper PLUS a hardcoded secret
# ======================================================================
# What the agent's round-1 edit actually did to the two files:
printf '\ndef multiply(a, b):\n    return a * b\n' >> calc.py
printf '\nSTRIPE_API_KEY = "sk_live_51H8x2example_do_not_commit"\n' >> config.py

git status
git diff

# Review catches the hardcoded key in config.py -- reject the whole change
git restore calc.py config.py
git status   # back to a clean checkpoint, nothing lost

# ======================================================================
# ROUND 2 -- a GOOD agent edit: a well-scoped function + test
# ======================================================================
# What the agent's round-2 edit actually did to the two files:
printf '\ndef subtract(a, b):\n    return a - b\n' >> calc.py
printf '\ndef test_subtract():\n    assert subtract(5, 3) == 2\n' >> test_calc.py
sed -i 's/from calc import add$/from calc import add, subtract/' test_calc.py

git diff

# Run the test suite before trusting the change
python -c "import test_calc; test_calc.test_add(); test_calc.test_subtract(); print('2 passed')"

export GIT_AUTHOR_DATE="2026-02-01T09:20:00"
export GIT_COMMITTER_DATE="2026-02-01T09:20:00"
git add calc.py test_calc.py
git commit -m "Add subtract() function with test (reviewed AI agent edit)"
git log --oneline
You should see
ပထမပတ်ရဲ့ `git diff` က simulate လုပ်ထားတဲ့ agent ဘာတွေထိသွားလဲ အတိအကျ ပြပါတယ် —

diff --git a/calc.py b/calc.py
index 4693ad3..3581473 100644
--- a/calc.py
+++ b/calc.py
@@ -1,2 +1,6 @@
 def add(a, b):
     return a + b
+
+
+def multiply(a, b):
+    return a * b
diff --git a/config.py b/config.py
index 9b58e1e..5452405 100644
--- a/config.py
+++ b/config.py
@@ -2,3 +2,4 @@ import os
 
 DATABASE_URL = os.environ.get("DATABASE_URL", "postgres://localhost/myapp_dev")
 DEBUG = True
+STRIPE_API_KEY = "sk_live_51Hc9example1234567890abcdef"

`multiply()` ထပ်ထည့်တာက အန္တရာယ်မရှိပေမယ့်, `config.py` ထဲက hardcoded key က တကယ့်ပြဿနာပါ — ဒါကြောင့် change တစ်ခုလုံးကို ပယ်ချပါတယ်။ `git restore calc.py config.py` က `git status` ကို `nothing to commit, working tree clean` အဖြစ် ပြန်ရောက်စေပြီး, checkpoint commit ကို မထိခိုက်စေပါဘူး။

ဒုတိယပတ်ရဲ့ `git diff` က calc.py နဲ့ test_calc.py ကိုသာ ထိသွားပါတယ် — config (သို့) dependency file လုံးဝမပါဘူး —

diff --git a/calc.py b/calc.py
index 4693ad3..3b474e9 100644
--- a/calc.py
+++ b/calc.py
@@ -1,2 +1,6 @@
 def add(a, b):
     return a + b
+
+
+def subtract(a, b):
+    return a - b
diff --git a/test_calc.py b/test_calc.py
index d509f32..38c0994 100644
--- a/test_calc.py
+++ b/test_calc.py
@@ -1,5 +1,9 @@
-from calc import add
+from calc import add, subtract
 
 
 def test_add():
     assert add(2, 3) == 5
+
+
+def test_subtract():
+    assert subtract(5, 3) == 2

Test တွေ run လိုက်ရင် `2 passed` ဆိုပြီးပြပါတယ်။ ဒီတစ်ခါတော့ change ကို လက်ခံပါတယ် —

[main de6c5a8] Add subtract() function with test (reviewed AI agent edit)
 2 files changed, 9 insertions(+), 1 deletion(-)

၅ မိနစ် စမ်းကြည့်

AI coding agent တစ်ခုကို task ငယ်တစ်ခု ပေးလိုက်ရာ file နှစ်ခုကို တစ်ပြိုင်နက် ထိသွားပါတယ်။ `git diff` က `calc.py` ထဲမှာ function အသစ် `multiply()` — သန့်ရှင်း, test လုပ်ပြီးသားလို ထင်ရ, ထူးထူးခြားခြား မရှိတာကို ပြပြီး, အလားတူအချိန်တည်းမှာ `config.py` ထဲမှာ line အသစ်တစ်ခု — `STRIPE_API_KEY = "sk_live_51Hc9example1234567890abcdef"` ကိုပါ ပြပါတယ်။ ဘာမှ crash မဖြစ်ပါဘူး။ ထင်ရှားစွာ ပျက်နေသလို လည်း မရှိပါဘူး။ Function တစ်ခုတည်းဆိုရင် လက်ခံဖို့ ကောင်းတဲ့ change တစ်ခုပါ။ Agent ထိသွားတဲ့ file အားလုံးပေါ် `git add` မလုပ်ခင်, ဘာက မင်းကို ရပ်တန့်စေသင့်လဲ, ဒီ diff ထဲမှာ ဘယ် file သီးသန့်က ကျန်တာထက် ပိုပြီး အာရုံစိုက်ဖို့ လိုအပ်လဲ?

သတိလေးတစ်ချက်

Diff ကို မဖတ်ဘဲ agent ရဲ့ change ကို ချက်ချင်းcommit လုပ်တာက safety net တစ်ခုလုံးကို ပျက်ပြယ်စေပါတယ် — မယုံခင် review လုပ်တာကသာ အဓိကအချက်ပါ။

Agent ကို `git push --force`, `git reset --hard`, (သို့) history ပြန်ရေးတာကို သူ့ဘာသာသူ run ခွင့်ပေးလိုက်ရင် တစ်ခုခုမှားသွားရင် ပြန်ကယ်ဆယ်နိုင်တဲ့ အစွမ်းကို ဖျက်ပစ်လိုက်ရာရောက်ပါတယ်။

Pro Git -- Git Basics: Undoing ThingsGit & GitHub

Git & GitHub Glossary — အသုံးများသော ဝေါဟာရများ

Termအဓိပ္ပာယ်
Version Controlအချိန်နှင့်အမျှ file အပြောင်းအလဲများကို မှတ်တမ်းတင်ပေးပြီး earlier version တစ်ခုခုကို ပြန်ကြည့်/ပြန်ရယူနိုင်စေသော စနစ်တစ်ခု။
GitProject ရဲ့ history ကို ကိုယ့် machine ပေါ်မှာ local အနေနဲ့ tracking လုပ်ပေးသော distributed version-control tool။
GitHubGit ပေါ်မှာ တည်ဆောက်ထားပြီး repository host လုပ်ပေးပြီး Pull Request, Issue, Actions လို collaboration feature တွေ ထပ်ဖြည့်ပေးတဲ့ web platform။
RepositoryGit က track လုပ်နေတဲ့ folder — file များနှင့် သူတို့ရဲ့ history အပြည့်အစုံ ပါဝင်သည်။
Local Repositoryကိုယ့် machine ပေါ်မှာရှိတဲ့ repository copy — commit အမှန်တကယ် ပြုလုပ်ရာနေရာ။
Remote RepositoryGitHub လိုနေရာမှာ host လုပ်ထားတဲ့ repository copy — local repository က push/pull လုပ်ရာ target။
Working DirectoryStage/commit မလုပ်ခင် အခု ပြင်ဆင်နေတဲ့ disk ပေါ်က file အမှန်များ။
Staging Area`git add` ပြီးနောက် `git commit` မလုပ်ခင် အပြောင်းအလဲတွေ စောင့်နေတဲ့ index/holding area။
CommitStaged changes ကို repository history ထဲ အမြဲတမ်းမှတ်တမ်းတင်ထားတဲ့ snapshot။
Commit HashCommit တစ်ခုချင်းစီကို တိတိကျကျ ရည်ညွှန်းရန် Git က ပေးအပ်သော ထူးခြားသည့် SHA identifier။
BranchCommit line တစ်ခုကို ညွှန်ပြနေတဲ့ ရွှေ့နိုင်တဲ့ pointer — အလုပ်လိုင်းအမျိုးမျိုးကို တစ်ပြိုင်နက် တီထွင်နိုင်စေသည်။
mainRepository ရဲ့ ပင်မ history line အတွက် ပုံမှန် default branch အမည်။
HEADWorking directory လက်ရှိ ရောက်နေတဲ့ commit ကို ညွှန်ပြနေတဲ့ pointer — များသောအားဖြင့် လက်ရှိ branch ရဲ့ tip။
Detached HEADHEAD က branch မဟုတ်ဘဲ commit တစ်ခုကို တိုက်ရိုက်ညွှန်ပြနေတဲ့ state — branch အသစ်မဖန်တီးရင် commit အသစ်တွေက branch ဘယ်တစ်ခုမှာမှ မပါဝင်ပါ။
MergeBranch တစ်ခုရဲ့ change တွေကို နောက်ထပ်ခုနှင့် ပေါင်းစည်းပြီး history နှစ်ခုကို ချိတ်ဆက်တဲ့ commit အသစ်တစ်ခု ဖန်တီးသည်။
Merge Conflictလိုင်းတူတူပေါ်က change နှစ်ခုကို Git အလိုအလျောက် ပေါင်းစည်းမရတဲ့ အခြေအနေ — ကိုယ်တိုင်ဖြေရှင်းရန် တောင်းဆိုသည်။
CloneRemote repository ရဲ့ history အပြည့်အစုံပါ copy တစ်ခုလုံးကို ကိုယ့် machine ပေါ် download ဆွဲယူခြင်း။
Forkမူရင်းကို မထိခိုက်ဘဲ လွတ်လပ်စွာ ပြင်ဆင်နိုင်တဲ့ တခြားသူ့ GitHub repository ရဲ့ ကိုယ်ပိုင် independent copy။
RemoteRepository ရဲ့ တခြား copy တစ်ခု (အများအားဖြင့် GitHub ပေါ်ရှိတာ) ကို ရည်ညွှန်းသော အမည်တစ်ခု။
originRepository ကို clone လုပ်ခဲ့ရာ remote ကို Git ပေးအပ်တဲ့ ပုံမှန် default အမည်။
Pushကိုယ့် local commit တွေကို တခြားသူများ မြင်နိုင်ရန် remote repository ဆီ ပို့ပေးခြင်း။
PullRemote ကနေ commit တွေကို fetch ဆွဲယူပြီး ကိုယ့် လက်ရှိ local branch ထဲ တစ်ဆင့်တည်းနဲ့ merge လုပ်ခြင်း။
FetchRemote ရဲ့ နောက်ဆုံး commit နှင့် branch များကို ကိုယ့် working branch ထဲ merge မလုပ်ဘဲ download ဆွဲယူခြင်း။
Pull RequestBranch တစ်ခုရဲ့ change တွေကို နောက်တစ်ခုထဲ merge ဖို့ တောင်းဆိုတဲ့ GitHub feature — ဆွေးနွေးမှု/review အတွက် နေရာဖွင့်ပေးသည်။
Code ReviewMerge မလုပ်ခင် အခြားသူတစ်ဦးက proposed change ကို စစ်ဆေးပေးတဲ့ practice — bug ဖမ်းရန်နှင့် knowledge မျှဝေရန်။
IssueBug တင်ပြရန်၊ feature တောင်းဆိုရန်၊ project အလုပ်ဆွေးနွေးရန် အသုံးပြုတဲ့ GitHub tracker entry။
TagCommit တိကျတစ်ခုကို ညွှန်ပြနေတဲ့ ပုံသေ named pointer — history ထဲက release point ကို မှတ်သားရန် သုံးလေ့ရှိသည်။
Semantic VersioningRelease တစ်ခုက breaking, additive, (သို့) fix ဟုတ်မဟုတ် ညွှန်ပြသော MAJOR.MINOR.PATCH version-number ချမှတ်ပုံစံ။
ReleaseTag တစ်ခုမှာရှိတဲ့ repository ရဲ့ packaged, named snapshot — build artifact နှင့် release note ပါဝင်လေ့ရှိသည်။
RebaseBranch ရဲ့ commit များကို base commit အသစ်တစ်ခုပေါ် ပြန်လည် ကစားပြသခြင်း — ဖြောင့်တန်း linear history ရရှိစေသည်။
Resetလက်ရှိ branch pointer ကို commit တခြားတစ်ခုသို့ ရွှေ့ခြင်း — staging area နှင့် working directory ကိုပါ ရွေးချယ်၍ ပြောင်းနိုင်သည်။
RevertHistory ကို ပြန်မရေးဘဲ ယခင် commit ရဲ့ change ကို ပြန်ဖျက်ပေးတဲ့ commit အသစ်တစ်ခု ဖန်တီးခြင်း။
StashUncommitted change တွေကို ယာယီသိမ်းဆည်းထားပြီး context ပြောင်းကာ နောက်မှ ပြန်သုံးနိုင်စေသည်။
Cherry-pickတခြား branch က commit သီးသန့်တစ်ခုကို ကိုယ့်လက်ရှိ branch ပေါ် ကူးယူ အသုံးပြုခြင်း။
BisectKnown-good နှင့် known-bad point ကြားက commit များကို စမ်းသပ်ပြီး bug စတင်ခဲ့တဲ့ commit အတိအကျကို ရှာဖွေပေးတဲ့ binary-search tool။
ReflogHEAD နှင့် branch များ ရောက်ဖူးသမျှ နေရာအားလုံးကို Git က မှတ်ထားတဲ့ local log — ပျောက်သွားသလို ထင်ရတဲ့ commit ပြန်ရှာရန် အသုံးဝင်သည်။
Git HookCommit မလုပ်ခင် (သို့) push မလုပ်ခင်လို workflow ရဲ့ သတ်မှတ်အချိန်တွင် Git က အလိုအလျောက် run ပေးတဲ့ script။
CIContinuous Integration — push လုပ်လိုက်တာနဲ့ change တိုင်းကို အလိုအလျောက် build/test လုပ်ခြင်း။
CDContinuous Delivery/Deployment — CI အောင်မြင်ပြီးနောက် passing build ကို user များထံ အလိုအလျောက် ပြင်ဆင်/ပို့ဆောင်ခြင်း။
GitHub ActionsRepository တစ်ခုထဲကနေ CI/CD workflow များကို တိုက်ရိုက် run နိုင်တဲ့ GitHub ရဲ့ built-in automation platform။
SecretAPI key (သို့) password လို sensitive value — source code ထဲ commit မလုပ်ဘဲ လုံခြုံစွာ သိမ်းထားရမည်။
SSHPassword ထပ်ခါထပ်ခါ မရိုက်ဘဲ network ပေါ်က GitHub ကို authenticate လုပ်ရန် သုံးလေ့ရှိတဲ့ လုံခြုံသော protocol။
Personal Access TokenScript, tool, (သို့) HTTPS Git operation များ authenticate လုပ်ရန် GitHub ပေါ်မှာ ဖန်တီးထားသော password-like credential။
OrganizationRepository များစွာကို ထိန်းသိမ်းပြီး team member permission များကို အုပ်စုလိုက် စီမံပေးသော GitHub shared account။
Branch Protection`main` လို branch ကို update မလုပ်ခင် review (သို့) CI အောင်မြင်မှု စတဲ့ check တွေ လိုအပ်စေတဲ့ GitHub repository setting များ။
Open SourceSource code ကို လူတိုင်း ကြည့်ရှု၊ အသုံးပြု၊ ပြင်ဆင်၊ contribute လုပ်နိုင်အောင် အများသုံးဖွင့်ထားတဲ့ software။

Git Command Cheat Sheet

Commandဘာလုပ်တာလဲ
git initလက်ရှိ folder ထဲမှာ Git repository အသစ်တစ်ခု ဖန်တီးသည်။
git clone <url>Remote repository ကို history အပြည့်အစုံနှင့် download ဆွဲယူသည်။
git statusWorking directory နှင့် staging area ရဲ့ လက်ရှိ state ကို ပြသသည်။
git logCommit history ကို ပြသသည်; compact branch map အတွက် --oneline --graph --all ထည့်နိုင်သည်။
git diffStage/commit မလုပ်ခင် ဘာတွေ ပြောင်းလဲသွားလဲ line အလိုက် အတိအကျ ပြသသည်။
git add <file>Change တစ်ခုကို working directory ကနေ staging area ထဲ ရွှေ့သည်။
git commit -m "..."Staged change များကို history ထဲ ပုံသေ snapshot အသစ်တစ်ခုအဖြစ် သိမ်းဆည်းသည်။
git branchBranch များကို list ပြ/ဖန်တီး/ဖျက်နိုင်သည်။
git switch <branch>Working directory ကို branch တခြားတစ်ခုသို့ ညွှန်စေသည်။
git merge <branch>တခြား branch ရဲ့ change တွေကို လက်ရှိ branch ထဲ ပေါင်းစည်းသည်။
git remote -vRepository သိထားသော remote များနှင့် သူတို့ရဲ့ URL များကို list ပြသည်။
git fetchRemote ရဲ့ နောက်ဆုံး commit/branch များကို merge မလုပ်ဘဲ download ဆွဲယူသည်။
git pullRemote ရဲ့ change များကို fetch ပြီး လက်ရှိ branch ထဲ တစ်ဆင့်တည်း merge လုပ်သည်။
git pushLocal commit များကို remote repository ဆီ ပို့သည်။
git tag <name>လက်ရှိ commit ကို ပုံသေ named pointer နှင့် မှတ်သားသည် — များသောအားဖြင့် release အတွက်။
git restore <file>History ကို မထိခိုက်ဘဲ file တစ်ခုရဲ့ uncommitted change ကို ဖျက်ပစ် (သို့) unstage လုပ်သည်။
git revert <commit>History ကို မပျက်စေဘဲ commit အသစ်တစ်ခု ဖန်တီးပြီး commit တစ်ခုရဲ့ change ကို ဘေးကင်းစွာ ပြန်ဖျက်သည်။
git reset <commit>Local history ကို ပြန်ရေးပြီး လက်ရှိ branch pointer ကို commit တခြားတစ်ခုသို့ ရွှေ့သည်။
git rebase <branch>Branch ရဲ့ commit များကို base အသစ်ပေါ် ပြန်ကစားပြပြီး history ဖြောင့်တန်းစေသည်။
git cherry-pick <commit>တခြား branch က commit သီးသန့်တစ်ခုကို လက်ရှိ branch ပေါ် ကူးယူသည်။
git stashUncommitted change များကို context သန့်ရှင်းစွာ ပြောင်းနိုင်ရန် ယာယီသိမ်းထားသည်။
git reflogHEAD ရောက်ဖူးသမျှ နေရာအားလုံးကို ပြသည် — 'ပျောက်သွားသလို' commit ပြန်ရှာရန် အသုံးဝင်သည်။
git bisectBug ဘယ်ကစတင်ခဲ့သလဲ တိတိကျကျ ရှာရန် commit history ကို binary-search လုပ်သည်။

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • Diff ကို မဖတ်ဘဲ agent ရဲ့ change ကို ချက်ချင်းcommit လုပ်တာက safety net တစ်ခုလုံးကို ပျက်ပြယ်စေပါတယ် — မယုံခင် review လုပ်တာကသာ အဓိကအချက်ပါ။
  • Agent ကို `git push --force`, `git reset --hard`, (သို့) history ပြန်ရေးတာကို သူ့ဘာသာသူ run ခွင့်ပေးလိုက်ရင် တစ်ခုခုမှားသွားရင် ပြန်ကယ်ဆယ်နိုင်တဲ့ အစွမ်းကို ဖျက်ပစ်လိုက်ရာရောက်ပါတယ်။
  • Destructive (သို့) history ပြောင်းလဲနိုင်တဲ့ command တိုင်းကို run မခင် git status နဲ့ လက်ရှိအခြေအနေကို အမြဲစစ်ပါ။

လေ့ကျင့်ခန်း

AI coding agent တစ်ခုကို task ငယ်တစ်ခု ပေးလိုက်ရာ file နှစ်ခုကို တစ်ပြိုင်နက် ထိသွားပါတယ်။ `git diff` က `calc.py` ထဲမှာ function အသစ် `multiply()` — သန့်ရှင်း, test လုပ်ပြီးသားလို ထင်ရ, ထူးထူးခြားခြား မရှိတာကို ပြပြီး, အလားတူအချိန်တည်းမှာ `config.py` ထဲမှာ line အသစ်တစ်ခု — `STRIPE_API_KEY = "sk_live_51Hc9example1234567890abcdef"` ကိုပါ ပြပါတယ်။ ဘာမှ crash မဖြစ်ပါဘူး။ ထင်ရှားစွာ ပျက်နေသလို လည်း မရှိပါဘူး။ Function တစ်ခုတည်းဆိုရင် လက်ခံဖို့ ကောင်းတဲ့ change တစ်ခုပါ။ Agent ထိသွားတဲ့ file အားလုံးပေါ် `git add` မလုပ်ခင်, ဘာက မင်းကို ရပ်တန့်စေသင့်လဲ, ဒီ diff ထဲမှာ ဘယ် file သီးသန့်က ကျန်တာထက် ပိုပြီး အာရုံစိုက်ဖို့ လိုအပ်လဲ?

You'll know it worked when: ပထမပတ်ရဲ့ `git diff` က simulate လုပ်ထားတဲ့ agent ဘာတွေထိသွားလဲ အတိအကျ ပြပါတယ် — diff --git a/calc.py b/calc.py index 4693ad3..3581473 100644 --- a/calc.py +++ b/calc.py @@ -1,2 +1,6 @@ def add(a, b): return a + b + + +def multiply(a, b): + return a * b diff --git a/config.py b/config.py index 9b58e1e..5452405 100644 --- a/config.py +++ b/config.py @@ -2,3 +2,4 @@ import os DATABASE_URL = os.environ.get("DATABASE_URL", "postgres://localhost/myapp_dev") DEBUG = True +STRIPE_API_KEY = "sk_live_51Hc9example1234567890abcdef" `multiply()` ထပ်ထည့်တာက အန္တရာယ်မရှိပေမယ့်, `config.py` ထဲက hardcoded key က တကယ့်ပြဿနာပါ — ဒါကြောင့် change တစ်ခုလုံးကို ပယ်ချပါတယ်။ `git restore calc.py config.py` က `git status` ကို `nothing to commit, working tree clean` အဖြစ် ပြန်ရောက်စေပြီး, checkpoint commit ကို မထိခိုက်စေပါဘူး။ ဒုတိယပတ်ရဲ့ `git diff` က calc.py နဲ့ test_calc.py ကိုသာ ထိသွားပါတယ် — config (သို့) dependency file လုံးဝမပါဘူး — diff --git a/calc.py b/calc.py index 4693ad3..3b474e9 100644 --- a/calc.py +++ b/calc.py @@ -1,2 +1,6 @@ def add(a, b): return a + b + + +def subtract(a, b): + return a - b diff --git a/test_calc.py b/test_calc.py index d509f32..38c0994 100644 --- a/test_calc.py +++ b/test_calc.py @@ -1,5 +1,9 @@ -from calc import add +from calc import add, subtract def test_add(): assert add(2, 3) == 5 + + +def test_subtract(): + assert subtract(5, 3) == 2 Test တွေ run လိုက်ရင် `2 passed` ဆိုပြီးပြပါတယ်။ ဒီတစ်ခါတော့ change ကို လက်ခံပါတယ် — [main de6c5a8] Add subtract() function with test (reviewed AI agent edit) 2 files changed, 9 insertions(+), 1 deletion(-)

လေ့ကျင့်ခန်း — AI Coding Agent များနှင့် Git ကို ဘေးကင်းစွာ အသုံးပြုခြင်း | Thuta Learning