แผนการเรียนรู้
/

DevOps - 02 Git

qrcode

การควบคุมเวอร์ชันด้วย Git

Git คือระบบควบคุมเวอร์ชันแบบกระจายศูนย์ (Distributed VCS) ที่ช่วยให้ทีมพัฒนาซอฟต์แวร์สามารถบันทึกการเปลี่ยนแปลงของโค้ด ติดตามประวัติ และทำงานร่วมกันได้อย่างมีประสิทธิภาพสูงสุด

หัวใจสำคัญ

  • การติดตามประวัติ (History): บันทึกทุกการเปลี่ยนแปลง (Snapshots) และสามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าได้
  • ระบบกระจายศูนย์ (Distributed): นักพัฒนาทุกคนมีสำเนาของ Repository ทั้งหมด ทำให้ทำงานได้แม้ไม่มีอินเทอร์เน็ต
  • Branching & Merging: รองรับการแยกสาขาเพื่อพัฒนาฟีเจอร์ใหม่และการรวมโค้ดที่รวดเร็ว
  • การทำงานร่วมกัน (Collaboration): เชื่อมต่อกับ Remote Repository (เช่น GitHub) เพื่อการทำงานเป็นทีม
สัปดาห์ที่ 2: บรรยาย

ระบบควบคุมเวอร์ชันคืออะไร? (What is Version Control?)

ระบบที่ทำหน้าที่บันทึกการเปลี่ยนแปลงของไฟล์หรือชุดไฟล์เมื่อเวลาผ่านไป เพื่อให้คุณสามารถเรียกดูเวอร์ชันเฉพาะในอดีตกลับมาได้ [1]

ทำไมต้องใช้?

  • ย้อนกลับ (Revert): กู้คืนไฟล์หรือทั้งโปรเจกต์กลับสู่สถานะก่อนหน้า [1]
  • เปรียบเทียบ (Compare): ดูความเปลี่ยนแปลงที่เกิดขึ้นเมื่อเวลาผ่านไป [1]
  • ตรวจสอบ (Audit): ดูว่าใครเป็นคนแก้ไขและแก้ไขเมื่อไหร่ [1]
  • กู้คืน (Recover): ป้องกันความเสียหายจากการลบไฟล์ผิดพลาด [1]

"ถ้าคุณเป็นกราฟิกดีไซเนอร์หรือนักพัฒนาเว็บ คุณย่อมต้องการเก็บทุกเวอร์ชันของงานไว้ VCS คือสิ่งที่ฉลาดที่สุดที่จะนำมาใช้" [1]

วิวัฒนาการของระบบ VCS

1. Local VCS (เช่น RCS)

เก็บฐานข้อมูลการเปลี่ยนแปลงไว้บนเครื่องคอมพิวเตอร์เพียงเครื่องเดียว ง่ายแต่เสี่ยงต่อการสูญหายหากฮาร์ดดิสก์พัง [2]

2. Centralized VCS (เช่น Subversion, CVS)

มีเซิร์ฟเวอร์กลางเก็บไฟล์ทุกเวอร์ชัน ทุกคนดึงไฟล์จากที่นี่ ข้อดีคือจัดการง่าย แต่ถ้าเซิร์ฟเวอร์ล่ม ทุกคนทำงานต่อไม่ได้ [2]

3. Distributed VCS (เช่น Git, Mercurial)

ไคลเอนต์ไม่ได้แค่ดึงไฟล์ล่าสุด แต่ "โคลน" (Mirror) ฐานข้อมูลทั้งหมดมาไว้ที่เครื่องตัวเอง ทำให้ทำงานได้แม้ไม่มีอินเทอร์เน็ตและสำรองข้อมูลได้สมบูรณ์ [3]

Git คืออะไร?

ถือกำเนิดขึ้นในปี 2005 โดย Linus Torvalds เพื่อใช้พัฒนา Linux Kernel โดยเน้นแก้ปัญหาของระบบแบบเดิม [3]

เป้าหมายหลักของการออกแบบ

🚀 ความเร็ว (Speed): ทำงานได้รวดเร็วมาก
Simple การออกแบบที่เรียบง่าย: โครงสร้างไม่ซับซ้อน
🌿 Branching: รองรับการแตกสาขาแบบ Non-linear ได้ดีเยี่ยม
Distributed กระจายศูนย์: ทำงานแบบ Distributed เต็มรูปแบบ

สถาปัตยกรรม Git: Snapshots ไม่ใช่ Deltas

ความแตกต่างที่สำคัญที่สุดของ Git คือวิธีการเก็บข้อมูล [4]

ระบบอื่น (Deltas)

เก็บข้อมูลเป็นรายการของ "ความเปลี่ยนแปลง" (Changeset) ของแต่ละไฟล์ตามลำดับเวลา

File A (v1) -> Change -> Change

Git (Snapshots)

เก็บภาพรวม (Snapshot) ของไฟล์ทั้งหมด ณ ขณะนั้น ถ้าไฟล์ไหนไม่เปลี่ยน Git จะไม่ออกไฟล์ใหม่ แต่จะชี้ลิงก์ไปที่ไฟล์เดิม [4]

Snapshot A -> Snapshot B -> Snapshot C

3 สถานะหลักของ Git (The Three States)

ไฟล์ใน Git จะอยู่ในสถานะใดสถานะหนึ่งต่อไปนี้เสมอ [5]

1

Modified (แก้ไขแล้ว)

คุณได้แก้ไขไฟล์แล้ว แต่ยังไม่ได้บันทึกลงในฐานข้อมูล (Working Directory)

2

Staged (เตรียมจัดเก็บ)

คุณได้เลือกไฟล์ที่แก้ไขแล้ว เพื่อเตรียมไว้สำหรับการ Commit ครั้งต่อไป (Staging Area)

3

Committed (บันทึกแล้ว)

ข้อมูลถูกบันทึกลงในฐานข้อมูลของ Git อย่างปลอดภัยแล้ว (.git directory)

การตั้งค่าเริ่มต้น (First-Time Setup)

สิ่งแรกที่ต้องทำหลังติดตั้ง Git คือการระบุตัวตนของคุณ เพราะข้อมูลนี้จะถูกฝังอยู่ในทุก Commit [5]

# ตั้งชื่อผู้ใช้

$ git config --global user.name "John Doe"

# ตั้งอีเมล (สำคัญสำหรับ GitHub/GitLab)

$ git config --global user.email johndoe@example.com

# ตรวจสอบค่าที่ตั้งไว้

$ git config --list

หมายเหตุ: ใช้ --global เพื่อตั้งค่าเพียงครั้งเดียวสำหรับทุกโปรเจกต์ในเครื่องนี้ [5]

การเริ่มต้น Repository

📂

สร้างใหม่ (Initialize)

สำหรับเริ่มโปรเจกต์ใหม่ หรือนำโฟลเดอร์ที่มีอยู่เข้าสู่ Git

$ git init --bare djrepo.git

คำสั่งนี้จะสร้างโฟลเดอร์ย่อย .git ขึ้นมา [5]

☁️

คัดลอก (Clone)

สำหรับดาวน์โหลดโปรเจกต์ที่มีอยู่แล้วจาก Server (เช่น GitHub)

$ git clone <url>

คุณจะได้สำเนาประวัติทั้งหมดของโปรเจกต์นั้นมา [5]

$ git clone djrepo.git djlocal

คำสั่งนี้จะสร้างโคัดลอกต้นฉบับมาพัฒนาต่อยอดไว้ในโฟล์เดอร์ชื่อ djlocal

วงจรชีวิตของไฟล์ (The Lifecycle of a File)

Untracked
→
Unmodified
→
Modified
→
Staged

ตรวจสอบสถานะด้วย git status

  • Untracked: ไฟล์ใหม่ที่ Git ยังไม่ได้เริ่มเก็บข้อมูล
  • Unmodified: ไฟล์ที่มีในฐานข้อมูลแล้ว และยังไม่มีการแก้ไข
  • Modified: ไฟล์เดิมที่มีการแก้ไขเนื้อหา แต่ยังไม่ได้ Stage
  • Staged: ไฟล์ที่พร้อมจะถูก Commit ในรอบถัดไป [6]

การติดตามและเตรียมไฟล์ (Tracking & Staging)

คำสั่ง git add เป็นคำสั่งอเนกประสงค์ที่สำคัญมาก [7]

หน้าที่ของ git add

  • ✅ เริ่มติดตามไฟล์ใหม่ (Untracked → Staged)
  • ✅ เตรียมไฟล์ที่แก้ไขแล้ว (Modified → Staged)
  • ✅ ยืนยันการแก้ไขไฟล์ที่ชนกัน (Merge Conflicts)

# เพิ่มไฟล์เดียว

$ git add README.md

# เพิ่มทุกไฟล์ในโฟลเดอร์ปัจจุบัน

$ git add .

💡 คิดซะว่าเป็นการ "เพิ่มเนื้อหานี้ลงใน Commit ถัดไป" ไม่ใช่แค่การเพิ่มไฟล์เข้าโปรเจกต์ [7]

ดูความเปลี่ยนแปลง (Viewing Changes)

คำสั่ง git status บอกแค่ชื่อไฟล์ แต่ git diff บอกเนื้อหาที่เปลี่ยน [1]

Unstaged Changes

ดูสิ่งที่แก้ไปแต่ยังไม่ได้ Add

$ git diff

Staged Changes

ดูสิ่งที่จะถูก Commit (เทียบกับ Commit ล่าสุด)

$ git diff --staged

# หรือ --cached [2]

การบันทึก (Committing Changes)

การ Commit คือการบันทึก Snapshot ของ Staging Area ลงในประวัติ [3]

คำสั่งพื้นฐาน

$ git commit -m "ข้อความอธิบายสิ่งที่ทำ"

ทางลัด (ข้าม git add)

ใช้ -a เพื่อ Stage ไฟล์ที่ถูก Track อยู่แล้วทั้งหมดอัตโนมัติ [3]

$ git commit -a -m "Update existing files"
Best Practice: ใช้ประโยคคำสั่ง (Imperative) เช่น "Fix bug" ไม่ใช่ "Fixed bug" [4]

Branch คืออะไร?

  • ptr ตัวชี้ (Pointer): ใน Git, Branch เป็นเพียงตัวชี้เบาๆ ไปยัง Commit หนึ่ง [5]
  • 🏷️ Default: ชื่อ Branch หลักเริ่มต้นมักชื่อว่า master (หรือ main) [6]
  • 👀 HEAD: คือตัวชี้พิเศษที่บอกว่า "ตอนนี้เราอยู่ที่ Branch ไหน" [7]
C1
←
C2
←
C3
master
HEAD

HEAD ชี้ที่ master, master ชี้ที่ C3

การสร้างและสลับ Branch

1. สร้าง Branch ใหม่

$ git branch testing

สร้างตัวชี้ใหม่ชื่อ testing แต่ยังไม่ได้ย้ายไปที่นั่น [6]

2. สลับ (Switch) ไปยัง Branch

$ git checkout testing

ย้าย HEAD ไปชี้ที่ testing และเปลี่ยนไฟล์ใน Directory ให้ตรงกับ snapshot นั้น [8]

🚀 ทางลัด: สร้างและสลับในคำสั่งเดียว

$ git checkout -b feature-login

นิยมใช้มากที่สุด [9]

ทำไมต้อง Branch? (Use Cases)

การ Branch ใน Git ทำได้เร็วและ "ราคาถูก" (ใช้ทรัพยากรน้อย) จึงควรทำบ่อยๆ [10]

🛠️ Feature Branch

แยกการพัฒนาฟีเจอร์ใหม่ออกมา (เช่น iss53) เพื่อไม่ให้กระทบกับโค้ดหลักที่ใช้งานอยู่ จนกว่าจะเสร็จสมบูรณ์ [9]

🚑 Hotfix Branch

เมื่อเจอบั๊กใน Production สามารถสลับกลับมาที่ master สร้าง branch hotfix แก้ไขด่วน แล้ว Merge กลับ โดยไม่ต้องรอฟีเจอร์อื่นเสร็จ [11]

🧪 Experiment

ทดลองไอเดียใหม่ๆ ถ้าไม่เวิร์คก็แค่ลบทิ้ง (git branch -d) โดยไม่ทำให้ history หลักสกปรก [10]

🔄 Context Switching

สลับไปมาระหว่างงานต่างๆ ได้ทันทีโดยไม่ต้องกังวลเรื่องไฟล์ตีกัน [10]

การรวมโค้ด (Merging)

เมื่อทำงานใน Branch เสร็จแล้ว เราจะนำกลับมารวมที่ Branch หลัก

# 1. กลับไปที่ branch หลัก

$ git checkout master

# 2. สั่ง merge branch ที่ต้องการเข้ามารวม

$ git merge hotfix

Fast-forward

ถ้าประวัติเป็นเส้นตรง Git แค่เลื่อนตัวชี้ master ไปข้างหน้า (ไม่ต้องสร้าง Commit ใหม่) [12]

Three-way Merge

ถ้าประวัติแยกขาดจากกัน Git จะสร้าง "Merge Commit" ใหม่ที่มีพ่อแม่ 2 ทาง เพื่อรวมผลลัพธ์ [13]

ปัญหาการชนกัน (Merge Conflicts)

เกิดขึ้นเมื่อบรรทัดเดียวกันในไฟล์เดียวกัน ถูกแก้ไขต่างกันในสอง Branch [14]

<<<<<<< HEAD:index.html

<div id="footer">contact : email.support@github.com</div>

=======

<div id="footer">

please contact us at support@github.com

</div>

>>>>>>> iss53:index.html

Git จะหยุดกระบวนการ Merge และใส่เครื่องหมายไว้ในไฟล์เพื่อให้คุณตัดสินใจ [15]

การแก้ไข Conflict

1

แก้ไขไฟล์ (Manually Edit)

เปิดไฟล์ที่มีปัญหา เลือกว่าจะใช้โค้ดส่วนไหน แล้วลบเครื่องหมาย <<<, ===, >>> ออกให้หมด [16]

2

Mark as Resolved

ใช้คำสั่ง git add <filename> เพื่อบอก Git ว่าแก้เสร็จแล้ว [16]

3

Commit

ใช้คำสั่ง git commit เพื่อยืนยันการ Merge ให้สมบูรณ์ [17]

การทำงานกับ Remote

Remote คือเวอร์ชันของโปรเจกต์ที่โฮสต์อยู่บนอินเทอร์เน็ตหรือเครือข่ายอื่น (เช่น GitHub, GitLab) [18]

แสดงรายชื่อ Remote

$ git remote -v

output:

origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

origin คืออะไร?

เป็นชื่อเรียกเล่น (Shortname) มาตรฐานที่ Git ตั้งให้โดยอัตโนมัติเมื่อคุณสั่ง git clone จาก Server [18]

Fetching vs Pulling

การนำข้อมูลจาก Server ลงมาที่เครื่อง

git fetch

  • ✅ ดาวน์โหลดข้อมูลใหม่ทั้งหมดจาก Server
  • ❌ ไม่รวม (Merge) เข้ากับงานของคุณ
  • ❌ ไฟล์ในเครื่อง ไม่เปลี่ยน
  • 💡 ปลอดภัย ใช้เพื่อ "ดู" ว่ามีอะไรใหม่ [18]

git pull

  • ✅ ทำ git fetch
  • ✅ ทำ git merge ทันที
  • ⚠️ ไฟล์ในเครื่อง เปลี่ยน
  • 💡 สะดวก แต่ต้องระวัง Conflict [19]

การส่งงานขึ้น Server (Pushing)

เมื่อคุณพร้อมแบ่งปันงานกับทีม คุณต้อง "Push"

# รูปแบบคำสั่ง

$ git push <remote> <branch>

# ตัวอย่างการใช้งานจริง

$ git push origin master

ข้อควรระวัง:

คำสั่งนี้จะทำงานได้ก็ต่อเมื่อ:

  1. คุณมีสิทธิ์เขียน (Write access) บน Server
  2. ไม่มีใคร Push ตัดหน้าคุณ (ถ้ามี คุณต้อง pull มา Merge ก่อน) [20]

สรุปคำสั่งสำคัญ (Summary)

git init เริ่มสร้าง Repo ใหม่
git clone คัดลอก Repo จาก Server
git add เตรียมไฟล์ (Stage)
git commit บันทึกประวัติ
git status เช็คสถานะไฟล์
git branch จัดการ Branch
git merge รวม Branch
git pull ดึงงานจาก Server
git push ส่งงานขึ้น Server

กลยุทธ์การแตกสาขา

Git ให้เครื่องมือ แต่ไม่ได้ให้ "กฎ" ในการใช้งาน หากไม่มีกลยุทธ์ที่ตกลงกัน ทีมจะเจอปัญหา Merge Conflict และการ Deploy ที่ล่าช้า [1, 2]

GitFlow

โครงสร้างชัดเจน เหมาะกับการปล่อยซอฟต์แวร์เป็นเวอร์ชัน (Versioned Software) [3]

GitHub Flow

เรียบง่าย เน้นความเร็ว เหมาะสำหรับ Web Apps และ CI/CD [4]

Trunk-Based

ขั้นสูง รวมโค้ดบ่อยที่สุด ลด Conflict เหมาะกับทีมที่มีระบบ Automated Test แข็งแกร่ง [5]

1. GitFlow Strategy

โมเดลแบบดั้งเดิม (The Old Guard) ที่แยก Master (Production) ออกจาก Develop (Integration) อย่างชัดเจน [6]

GitFlow
  • Master: เก็บโค้ดที่อยู่บน Production เท่านั้น [7]
  • Develop: สาขาหลักสำหรับการรวมโค้ด (Integration) [8]
  • Feature: แยกออกมาจาก Develop เพื่อทำฟีเจอร์ใหม่ [8]
  • Release: แยกจาก Develop เพื่อเตรียมปล่อยเวอร์ชัน (QA/Docs) [9]
  • Hotfix: แยกจาก Master เพื่อแก้บั๊กเร่งด่วน แล้วรวมกลับทั้ง Master/Develop [10]

GitFlow: ข้อดีและข้อเสีย

ข้อดี (Pros)

  • ✅ โครงสร้างชัดเจน: ทุกคนรู้ว่า Branch ไหนทำหน้าที่อะไร [11]
  • ✅ Safe for Versions: เหมาะมากสำหรับซอฟต์แวร์ที่ต้อง Support หลายเวอร์ชันพร้อมกัน [3]
  • ✅ ความเสถียร: Master Branch สะอาดและเสถียรเสมอ เพราะผ่านการทดสอบจาก Release Branch มาแล้ว [12]

ข้อเสีย (Cons)

  • ❌ ซับซ้อน (Complexity): มี Overhead ในการจัดการ Branch เยอะเกินไปสำหรับทีมเล็ก [13]
  • ❌ Merge Hell: Feature Branch ที่แยกตัวนานๆ (Long-lived) ทำให้เกิด Conflict มหาศาลเมื่อต้องรวมโค้ด [14]
  • ❌ ไม่เหมาะกับ CI/CD: ออกแบบมาเพื่อการปล่อยของเป็นรอบๆ (Scheduled Release) ไม่ใช่การปล่อยรายวัน [14]

2. GitHub Flow Strategy

แนวคิด "Simple Sandwich" ที่ลดความซับซ้อนเหลือแค่ Master และ Feature Branches เหมาะสำหรับ Web/SaaS [15]

Github Flow

กฎทอง (Golden Rule):

"อะไรก็ตามที่อยู่ใน Main Branch จะต้องพร้อม Deploy เสมอ" [15]

  1. สร้าง Branch ใหม่จาก Main สำหรับทุกงาน
  2. เปิด Pull Request เพื่อคุยและรีวิวโค้ด [16]
  3. เมื่อผ่านการรีวิวและเทส ให้ Merge กลับ Main และ Deploy ทันที [4]

GitHub Flow: ข้อดีและข้อเสีย

ข้อดี (Pros)

  • ✅ รวดเร็วและเรียบง่าย: ลดขั้นตอนพิธีการ ไม่ต้องจัดการ Release Branch [4]
  • ✅ CI/CD Friendly: ออกแบบมาเพื่อ Continuous Deployment โดยเฉพาะ [17]
  • ✅ เหมาะกับ Web Apps: ที่มีการอัปเดตตลอดเวลาและมี Production เวอร์ชันเดียว [4]

ข้อเสีย (Cons)

  • ❌ ไม่มี Versioning: จัดการยากหากต้อง Support ลูกค้าที่ใช้ซอฟต์แวร์เวอร์ชันเก่า [18]
  • ❌ ความเสี่ยงสูง: หากเทสไม่ดีพอ การ Merge เข้า Main อาจทำให้ Production ล่มได้ทันที [19]
  • ❌ ต้องมีวินัยสูง: ทีมต้องเคร่งครัดเรื่อง Code Review และ Automated Test [18]

3. Trunk-Based Development

ระดับ Elite: นักพัฒนาทุกคน Commit โค้ดเข้าสู่ Main (Trunk) บ่อยๆ (วันละหลายครั้ง) [20]

Trunk-Based

Main Branch (The Trunk)

⬇️ Short-lived branches (hours)

⬇️ No long integration hell

Trunk-Based: ข้อดีและข้อเสีย

ข้อดี (Pros)

  • ✅ ความเร็วสูงสุด: Feedback loop สั้นมาก รู้ผลทันทีว่าโค้ดพังหรือไม่ [22]
  • ✅ Zero Merge Hell: เพราะรวมโค้ดทีละนิดตลอดเวลา จึงไม่มี Conflict ก้อนโต [22]
  • ✅ บังคับทำ Automation: ทีม "จำเป็น" ต้องมีระบบ Test ที่ดีเยี่ยม [23]

ข้อเสีย (Cons)

  • ❌ ยากสำหรับมือใหม่: Junior Developer อาจทำ Production พังได้ง่ายๆ [23]
  • ❌ ต้องใช้เครื่องมือสูง: ต้องมีระบบ Feature Flags และ Automated Testing ที่ครอบคลุม (High Maturity) [22]
  • ❌ Culture Shock: ต้องเปลี่ยนวัฒนธรรมการทำงานจากการ "ทำเสร็จค่อยส่ง" เป็น "ส่งตลอดเวลา" [23]

ควรเลือกกลยุทธ์ไหน?

Strategy Release Frequency Team Maturity Best For
Git Flow รายเดือน / ไตรมาส ปานกลาง - สูง Open Source, ซอฟต์แวร์ที่ต้องติดตั้ง (Mobile Apps) [24]
GitHub Flow รายวัน / ต่อเนื่อง เริ่มต้น - ปานกลาง Web Apps, SaaS, ทีมขนาดเล็ก-กลาง [4]
Trunk-Based หลายครั้งต่อวัน สูง (Elite) ทีม DevOps ที่เชี่ยวชาญ, องค์กรใหญ่ (Google/Netflix) [20]

💡 คำแนะนำ: เริ่มต้นด้วย GitHub Flow หากคุณเป็นทีมเว็บทั่วไป เพราะสมดุลดีที่สุดระหว่างความง่ายและความเร็ว [25]

Lab Assignment: Django & Git Collaboration

ปฏิบัติการ: จำลองการทำงานร่วมกันด้วย Git, GitHub และ PythonAnywhere

ภารกิจ (Mission)

  • ☁️ Cloud: สร้าง Django App บน PythonAnywhere
  • 📦 Repository: สร้างและตั้งค่า GitHub Repo สำหรับโปรเจกต์
  • 🤝 Collaborator: เพิ่มเพื่อนและอาจารย์เป็นผู้ร่วมงาน
  • 🔀 Workflow: ฝึกฝนการ Fork, Clone, Edit, Commit, Push
  • 🔄 Integration: ส่ง Pull Request (PR) และทำการ Merge

จับคู่ 2 คน เพื่อเริ่มทำปฏิบัติการนี้

Step 1: PythonAnywhere Setup

1. สร้าง Web App

  • สมัคร/Login ที่ pythonanywhere.com
  • ไปที่แท็บ Web -> Add a new web app
  • เลือก Django และ Python 3.13
  • ตั้งชื่อโปรเจกต์ว่า mysite (ค่า Default)

2. เตรียมไฟล์ Source Code

เปิด Bash Console บน PythonAnywhere แล้วรันคำสั่ง:

$ zip -r mysite.zip mysite
  • ไปที่แท็บ Files
  • ดาวน์โหลดไฟล์ mysite.zip ลงมาที่เครื่องคอมพิวเตอร์ของคุณ

Step 2: GitHub Repository Setup

1. สร้าง Repository

สร้าง Public Repository ชื่อ mysite บน GitHub

เพิ่มไฟล์ README.md โดยระบุข้อมูลดังนี้:

1,ชื่อ-สกุล,GitHubUser,user.pythonanywhere.com
2,

*บรรทัดที่ 2 เว้นว่างไว้สำหรับเพื่อน

2. เพิ่ม Collaborators

ไปที่ Settings -> Collaborators ของ Repo ที่เพิ่งสร้าง

  • เพิ่มบัญชี GitHub ของ คู่หูของคุณ
  • เพิ่มบัญชี: wichit2s (อาจารย์)

💡 สำคัญ: ทำทั้ง 2 คน (ต่างคนต่างสร้าง Repo ของตัวเอง)

Step 3: Local Setup (VS Code)

1. Clone: เปิด VS Code แล้ว Clone Repo ของคุณมาที่เครื่อง $ git clone https://github.com/YourUser/mysite.git
2. Unzip Code: แตกไฟล์ mysite.zip แล้วนำไฟล์ทั้งหมดในโฟลเดอร์ mysite ไปใส่ในโฟลเดอร์ที่ Clone มา
3. Git Ignore: สร้างไฟล์ .gitignore แล้วนำเนื้อหาจาก Link นี้ไปใส่ gist.githubusercontent.com/.../.gitignore
4. Push: ส่ง Code ขึ้น Server
$ git add . $ git commit -m "Initial Django App" $ git push

Step 4: Cross-Collaboration (Fork & Edit)

สลับบทบาท! ตอนนี้ให้ไปทำงานบน Repo ของเพื่อน

1. Fork Repo เพื่อน

ไปที่หน้า GitHub ของเพื่อน กดปุ่ม Fork เพื่อสร้างสำเนามาเป็นของเรา

2. Clone Fork มาแก้

$ git clone https://github.com/YourUser/FriendRepo.git

แก้ไขไฟล์ README.md โดยเติมข้อมูลของคุณลงในบรรทัดที่ 2

3. Commit & Push (To Your Fork)

$ git add README.md

$ git commit -m "Add collaborator info"

$ git push

*ตอนนี้ข้อมูลอยู่ที่ Fork ของเรา ยังไม่ไปที่ต้นฉบับของเพื่อน

Step 5: Pull Request & Merge

🔀

ส่ง Pull Request (PR)

ไปที่หน้า Fork ของคุณบน GitHub กดปุ่ม "Compare & pull request" ส่งคำขอรวมโค้ดไปยัง Repo ต้นฉบับของเพื่อน

👀

Review & Merge

เจ้าของ Repo (เพื่อน) เข้าไปดู PR ตรวจสอบความถูกต้อง แล้วกดปุ่ม "Merge pull request"

🎉 เมื่อเสร็จสิ้น ใน README.md ของทั้งคู่จะมีข้อมูลครบ 2 คน

การส่งงาน (Submission)

🚀

สิ่งที่ต้องส่ง

ส่งลิงก์ GitHub Repository ของตัวเอง
(ที่มี Code Django และ README.md ที่มีชื่อครบ 2 คนแล้ว)

https://github.com/YourUsername/mysite
ตรวจสอบให้แน่ใจว่า Repo เป็น Public และเพิ่ม Collaborators ครบถ้วน