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

ပရောဂျက် — Professional Release တစ်ခု အစအဆုံး

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

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

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

ဒီ capstone project က ပြီးခဲ့တဲ့ အခန်းနှစ်ခုက concept အားလုံးနီးပါးကို professional team တွေ အစအဆုံး run နေတဲ့ pipeline တစ်ခုထဲမှာ ချိတ်ဆက်ပေးထားပါတယ်။

  • Issue — code မရေးခင် အလုပ်ရဲ့ အရေးကြီးမှုကို ဖမ်းယူတယ်
  • Branch — အသင့်မဖြစ်မချင်း main ကနေ ခွဲထားတယ်
  • Commits — change ကို သေးငယ်ပြီး review လုပ်လို့ရတဲ့ အဆင့်ဆင့်နဲ့ တည်ဆောက်တယ်
  • Pull request — change ကို team မြင်နိုင်အောင် ပြုလုပ်တယ်
  • CI — အလိုအလျောက်၊ objective ဖြစ်တဲ့ ပထမဆုံး စစ်ဆေးမှု
  • Code review — machine မပေးနိုင်တဲ့ လူ့ discretion
  • Merge (--no-ff) — change ကို ရောက်စေပြီး branch history ကို ထိန်းသိမ်းတယ်
  • Tag + Release — ship လုပ်ခဲ့တဲ့ တိကျတဲ့ state ကို နာမည်ပေးပြီး ထုတ်ပြန်တယ်

Git ကို fast-forward လုပ်ခိုင်းမည့်အစား --no-ff နဲ့ merge လုပ်ခြင်းက feature branch ရဲ့ commit တွေကို anonymous change တစ်ခုထဲ ညှစ်မထားဘဲ main ထဲမှာ ခွဲထင်ထင် unit တစ်ခုအဖြစ် ထိန်းသိမ်းပေးတယ်။

အဆင့်ဘာကြောင့် ရှိလဲ
Issuecode မရေးခင် ရည်ရွယ်ချက်နဲ့ context ကို မှတ်တမ်းတင်တယ်
CIလူတစ်ယောက် review အချိန်မကုန်ခင် objective ၊ automated စစ်ဆေးမှု
Code reviewcorrectness, style, edge case လွတ်ခဲ့တာတွေအတွက် လူ့ discretion
Tag + Releaseship လုပ်ခဲ့တဲ့အရာကို ထာဝရ၊ အဓိပ္ပာယ်ရှိတဲ့ နာမည်ပေးတယ်

Semantic Versioning: MAJOR.MINOR.PATCH

breaking change အတွက် MAJOR ကို တိုးပါ၊ နောက်ကွယ်ကို compatible ဖြစ်တဲ့ feature အသစ်အတွက် (ဒီ lesson ရဲ့ farewell() function လိုမျိုး) MINOR ကို တိုးပါ၊ compatible bug fix အတွက် PATCH ကို တိုးပါ။

text
ISSUE TO RELEASE: THE FULL PROFESSIONAL PIPELINE
------------------------------------------------
1. ISSUE          Someone opens issue #42 on GitHub describing
   (GitHub)        the needed change. No local git involved.
        |
        v
2. BRANCH         git checkout -b feature/add-farewell-function
   (local)         Isolates the work away from main.
        |
        v
3. COMMITS        git commit  (pinned author + timestamp, x2)
   (local)         Small, focused, well-described changes.
        |
        v
4. PUSH           git push -u origin feature/add-farewell-function
   (local)         Branch now exists on the shared/GitHub repo.
        |
        v
5. PULL REQUEST   Open a PR: feature-branch -> main (GitHub website)
   (GitHub)
        |
        v
6. CI             GitHub Actions runs the test suite automatically
   (GitHub)         on every push to the PR. Pass/fail shown inline.
        |
        v
7. CODE REVIEW    A teammate reads the diff, comments, approves
   (GitHub)         (or requests changes -- loop back to step 3).
        |
        v
8. MERGE          git merge --no-ff feature/add-farewell-function
   (local)          Keeps the branch's commits visible in history.
        |
        v
9. TAG            git tag -a v1.1.0 -m "Release v1.1.0 ..."
   (local)          Semantic version: MAJOR.MINOR.PATCH.
        |
        v
10. RELEASE       git push origin v1.1.0, then "Draft a new release"
    (GitHub)        from that tag, with release notes, published.

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

Issue ဖွင့်ပါ (GitHub)

တစ်ယောက်ယောက်က လိုအပ်တဲ့ feature ကို ဖော်ပြပြီး issue #42 ကို ဖွင့်ပါတယ်။ ဒီအဆင့်အတွက် local git equivalent မရှိပါဘူး — issue တွေက GitHub server ပေါ်မှာပဲ ရှိပါတယ်။

အလုပ်အတွက် branch ခွဲပါ

ဖြေရှင်းမယ့် issue ကို ကိုယ်စားပြုတဲ့ နာမည်နဲ့ git checkout -b feature/add-farewell-function လုပ်ပါ။

သေးငယ်၊ pinned အဆင့်တွေနဲ့ commit ပါ

focused commit နှစ်ခုနဲ့ change ကို ခွဲလုပ်ပါ၊ တစ်ခုစီမှာ pinned author နဲ့ timestamp အစစ်ပါစေပြီး branch ကို push လုပ်ပါ။

Pull Request ဖွင့်ပါ (GitHub)

သင့် branch ကနေ main ဆီ PR ဖွင့်ပြီး change ကို ရှင်းပြပြီး issue #42 ကို ကိုးကားပါ။

CI အလိုအလျောက် run ပါတယ် (GitHub)

branch ကို push လုပ်လိုက်တာနဲ့ GitHub Actions က test suite ကို run ပြီး pass/fail ကို pull request ပေါ်မှာ တိုက်ရိုက် ပြပါတယ်။

Code Review (GitHub)

teammate တစ်ယောက်က diff ကို ဖတ်၊ comment ချန်ပြီး approve လုပ်ပါတယ် — ဒါမှမဟုတ် change တောင်းဆိုပြီး အဆင့် 3 ကို ပြန်ပို့ချနိုင်ပါတယ်။

--no-ff နဲ့ Merge ပါ

CI အစိမ်းရောင်ဖြစ်ပြီး review approve ခံရပြီးတဲ့နောက် git merge --no-ff feature/add-farewell-function က branch ရဲ့ commit တွေကို main ရဲ့ history ထဲမှာ မြင်နိုင်အောင် ထားပေးပါတယ်။

Release ကို Tag ပါ

semantic versioning အတိုင်း merge commit ပေါ်မှာ git tag -a v1.1.0 လုပ်ပြီး tag ကို push လုပ်ပါ။

Release ကို Publish ပါ (GitHub)

Releases page မှာ tag v1.1.0 ကို ရွေးပြီး release note ရေးပြီး publish လုပ်ပါ — ဒါက release ကို user တွေ ရှာတွေ့၊ download လုပ်နိုင်တဲ့ အရာအဖြစ် ပြောင်းလဲပေးတဲ့ အခိုက်အတန့်ပါ။

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

bash
git init --bare /tmp/project.git
git clone /tmp/project.git /tmp/work
cd /tmp/work

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-03-01T09:00:00"
export GIT_COMMITTER_DATE="2026-03-01T09:00:00"

cat > app.py <<'EOF'
def greet(name):
    return f"Hello, {name}!"

if __name__ == "__main__":
    print(greet("World"))
EOF
git add app.py
git commit -m "Initial commit: v1.0.0 baseline app"
git push origin main

# 1. Issue #42 opened on GitHub: "Add a farewell() function" (web UI only)

# 2. Branch, isolated for this issue's work
git checkout -b feature/add-farewell-function

# 3. Two focused, pinned commits
export GIT_AUTHOR_DATE="2026-03-01T10:00:00"
export GIT_COMMITTER_DATE="2026-03-01T10:00:00"
cat >> app.py <<'EOF'

def farewell(name):
    return f"Goodbye, {name}!"
EOF
git add app.py
git commit -m "Add farewell() function (closes #42)"

export GIT_AUTHOR_DATE="2026-03-01T11:00:00"
export GIT_COMMITTER_DATE="2026-03-01T11:00:00"
cat >> app.py <<'EOF'

if __name__ == "__main__":
    print(farewell("World"))
EOF
git add app.py
git commit -m "Call farewell() in main block for demo output"

# 4. Push the branch -- this is what triggers CI and lets you open a PR
git push -u origin feature/add-farewell-function

# 5. PR opened on GitHub: feature/add-farewell-function -> main (web UI)
# 6. CI runs the test suite on the PR automatically (GitHub Actions)
# 7. A teammate reviews the diff and approves it (GitHub web UI)

# 8. Merge, preserving the feature branch as a visible unit in history
git checkout main
export GIT_AUTHOR_DATE="2026-03-01T14:00:00"
export GIT_COMMITTER_DATE="2026-03-01T14:00:00"
git merge --no-ff feature/add-farewell-function -m "Merge pull request #7 from feature/add-farewell-function

Add farewell() function (closes #42)"
git push origin main

# 9. Tag the release commit with a semantic version
export GIT_AUTHOR_DATE="2026-03-01T14:15:00"
export GIT_COMMITTER_DATE="2026-03-01T14:15:00"
git tag -a v1.1.0 -m "Release v1.1.0: add farewell() function"
git push origin v1.1.0

# 10. On GitHub: Releases -> Draft a new release -> choose tag v1.1.0 ->
#     write release notes -> Publish release (web UI)
You should see
ဒီ pipeline ရဲ့ git-mechanics ခြမ်းက ပြန်လုပ်လို့ရတဲ့ history တစ်ခုလုံးကို ထုတ်ပေးပါတယ်။ merge ပြီးနောက် main ပေါ်မှာ git log --oneline --graph က ဒီလို ပြပါတယ်:

*   c9c7c8c Merge pull request #7 from feature/add-farewell-function
|\
| * a4f106a Call farewell() in main block for demo output
| * c3aea86 Add farewell() function (closes #42)
|/
* 4a2cea7 Initial commit: v1.0.0 baseline app

merge ပြီးနောက် main ကို push လုပ်လိုက်ရင်:

   4a2cea7..c9c7c8c  main -> main

tag ကို push လုပ်လိုက်ရင်:

 * [new tag]         v1.1.0 -> v1.1.0

git show v1.1.0 --stat ကလည်း tag က merge commit ကို ညွှန်နေကြောင်း၊ tagger identity နဲ့ message ပါ ပြည့်စုံနေကြောင်း အတည်ပြုပါတယ်:

tag v1.1.0
Tagger: Thuta Learner <learner@example.com>
Release v1.1.0: add farewell() function
commit c9c7c8c...
Merge: 4a2cea7 a4f106a

GitHub ကိုယ်တိုင်ပေါ်မှာတော့ issue, pull request, CI check run, review comment, ပြီးတော့ publish လုပ်ထားတဲ့ Release page တို့ဟာ သင်တကယ်မြင်ရ၊ နှိပ်နိုင်တဲ့ UI element အစစ်တွေဖြစ်ပေမယ့် GitHub server ပေါ်မှာ record အနေနဲ့ပဲ ရှိလို့ ဖမ်းယူစရာ terminal output မရှိပါဘူး။

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

ဒုတိယ၊ ပိုသေးငယ်တဲ့ issue (#43) ကို ဖွင့်ပါ — 'hardcode ဖြစ်နေတဲ့ နေရာတိုင်းမှာ version ကို update လုပ်ပါ'။ v1.1.0 ရဲ့ merge commit ပါပြီးသား main ကနေ branch ခွဲပါ၊ 1.1.1 ပါဝင်တဲ့ VERSION file ထည့်ပါ၊ commit လုပ်ပါ၊ --no-ff နဲ့ ထပ်ပြီး merge လုပ်ပါ၊ ရလဒ်ကို v1.1.1 လို့ tag လုပ်ပါ — breaking change မရှိတဲ့ ပေါင်းထည့်မှုသေးသေးလေးဆို patch number ကိုပဲ တိုးရမယ်ဆိုတဲ့ semantic versioning စည်းကမ်းအတိုင်းပါ။ git tag --list နဲ့ v1.1.0 နဲ့ v1.1.1 နှစ်ခုစလုံး ရှိနေမရှိနေ အတည်ပြုပါ။

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

CI တကယ်မအောင်မြင်သေးခင်၊ pull request review မလုပ်ရသေးခင် main ကို tag လုပ်ပြီး release ထုတ်လိုက်တာကြောင့် မစစ်ဆေးရသေးတဲ့ code ပေါ်အခြေခံပြီး release ထုတ်ခြင်း။

publish လုပ်ပြီးသား tag (ဥပမာ bug တွေ့ပြီးနောက် v1.1.0 ကို ပြန် tag လုပ်တာ) ကို version အသစ်တစ်ခုအဖြစ် မတိုးဘဲ ပြန်သုံး/ရွှေ့နေခြင်း — publish လုပ်ပြီးသား tag ကို ထာဝရ၊ မပြောင်းလဲတဲ့အရာအဖြစ် သတ်မှတ်သင့်ပါတယ်။

GitHub Docs: Managing releases in a repositoryGit & GitHub

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

  • CI တကယ်မအောင်မြင်သေးခင်၊ pull request review မလုပ်ရသေးခင် main ကို tag လုပ်ပြီး release ထုတ်လိုက်တာကြောင့် မစစ်ဆေးရသေးတဲ့ code ပေါ်အခြေခံပြီး release ထုတ်ခြင်း။
  • publish လုပ်ပြီးသား tag (ဥပမာ bug တွေ့ပြီးနောက် v1.1.0 ကို ပြန် tag လုပ်တာ) ကို version အသစ်တစ်ခုအဖြစ် မတိုးဘဲ ပြန်သုံး/ရွှေ့နေခြင်း — publish လုပ်ပြီးသား tag ကို ထာဝရ၊ မပြောင်းလဲတဲ့အရာအဖြစ် သတ်မှတ်သင့်ပါတယ်။
  • Destructive (သို့) history ပြောင်းလဲနိုင်တဲ့ command တိုင်းကို run မခင် git status နဲ့ လက်ရှိအခြေအနေကို အမြဲစစ်ပါ။

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

ဒုတိယ၊ ပိုသေးငယ်တဲ့ issue (#43) ကို ဖွင့်ပါ — 'hardcode ဖြစ်နေတဲ့ နေရာတိုင်းမှာ version ကို update လုပ်ပါ'။ v1.1.0 ရဲ့ merge commit ပါပြီးသား main ကနေ branch ခွဲပါ၊ 1.1.1 ပါဝင်တဲ့ VERSION file ထည့်ပါ၊ commit လုပ်ပါ၊ --no-ff နဲ့ ထပ်ပြီး merge လုပ်ပါ၊ ရလဒ်ကို v1.1.1 လို့ tag လုပ်ပါ — breaking change မရှိတဲ့ ပေါင်းထည့်မှုသေးသေးလေးဆို patch number ကိုပဲ တိုးရမယ်ဆိုတဲ့ semantic versioning စည်းကမ်းအတိုင်းပါ။ git tag --list နဲ့ v1.1.0 နဲ့ v1.1.1 နှစ်ခုစလုံး ရှိနေမရှိနေ အတည်ပြုပါ။

You'll know it worked when: ဒီ pipeline ရဲ့ git-mechanics ခြမ်းက ပြန်လုပ်လို့ရတဲ့ history တစ်ခုလုံးကို ထုတ်ပေးပါတယ်။ merge ပြီးနောက် main ပေါ်မှာ git log --oneline --graph က ဒီလို ပြပါတယ်: * c9c7c8c Merge pull request #7 from feature/add-farewell-function |\ | * a4f106a Call farewell() in main block for demo output | * c3aea86 Add farewell() function (closes #42) |/ * 4a2cea7 Initial commit: v1.0.0 baseline app merge ပြီးနောက် main ကို push လုပ်လိုက်ရင်: 4a2cea7..c9c7c8c main -> main tag ကို push လုပ်လိုက်ရင်: * [new tag] v1.1.0 -> v1.1.0 git show v1.1.0 --stat ကလည်း tag က merge commit ကို ညွှန်နေကြောင်း၊ tagger identity နဲ့ message ပါ ပြည့်စုံနေကြောင်း အတည်ပြုပါတယ်: tag v1.1.0 Tagger: Thuta Learner <learner@example.com> Release v1.1.0: add farewell() function commit c9c7c8c... Merge: 4a2cea7 a4f106a GitHub ကိုယ်တိုင်ပေါ်မှာတော့ issue, pull request, CI check run, review comment, ပြီးတော့ publish လုပ်ထားတဲ့ Release page တို့ဟာ သင်တကယ်မြင်ရ၊ နှိပ်နိုင်တဲ့ UI element အစစ်တွေဖြစ်ပေမယ့် GitHub server ပေါ်မှာ record အနေနဲ့ပဲ ရှိလို့ ဖမ်းယူစရာ terminal output မရှိပါဘူး။

ပရောဂျက် — Professional Release တစ်ခု အစအဆုံး | Thuta Learning