DevOps พังแล้วพังอีกพังต่อ EP.3 — Git & Version Control

สวัสดีค่าา กลับมาอีกครั้งกับ EP.3!

เคยเป็นไหมคะ ทำ project งานแล้วก็มีไฟล์แบบนี้อยู่ใน folder

report_final.docx
report_final_v2.docx
report_final_v2_EDIT.docx
report_final_v2_EDIT_chao.docx
report_FINAL_USE_THIS_ONE.docx
report_FINAL_USE_THIS_ONE_actually_final.docx

5555 เราเชื่อว่าทุกคนเคยทำแบบนี้ รวมถึงตัวเราเองด้วย และ developer ทุกคนในโลกก็เคยทำแบบนี้กับโค้ดก่อนที่จะรู้จัก Git

Git คือคำตอบของปัญหานี้ค่ะ

Git คืออะไร

Git คือ version control system ที่ช่วยติดตามการเปลี่ยนแปลงของโค้ดทุกครั้ง มันเหมือนกับการที่ระบบจำทุก "checkpoint" ไว้ว่าโค้ดหน้าตาเป็นยังไง ณ แต่ละช่วงเวลา แล้วเราสามารถย้อนกลับไปได้ตลอด

ลองเปรียบกับการยกน้ำหนักนะ สมมติเราบันทึก training log ไว้ทุกวัน วันนี้ squat 80kg พรุ่งนี้ขึ้นเป็น 85kg สัปดาห์หน้า 90kg ถ้าวันไหนฟอร์มพัง เราก็กลับไปดูว่าตอน 80kg ท่าเป็นยังไง ย้อนกลับไปแก้จุดนั้นได้ Git ทำแบบเดียวกันกับโค้ดค่ะ

Concept หลักที่ต้องรู้

Repository (repo)

คือ folder ที่ Git ดูแลอยู่ ภายในจะมี folder ซ่อนชื่อ .git ที่เก็บ history ทั้งหมดไว้

Commit

คือการบันทึก snapshot ของโค้ด ณ ช่วงเวลานั้น แต่ละ commit มี message บอกว่าเปลี่ยนอะไรไป

Branch

คือสายการพัฒนาที่แยกออกมาจาก main เหมือนกับการที่ทีมนักยกน้ำหนักฝึก program ต่างกัน บางคนฝึก strength บางคนฝึก hypertrophy ก่อนที่สุดท้ายจะมา merge ผลลัพธ์กัน

Merge / Pull Request

การนำ branch ต่างๆมารวมกัน ใน GitHub/GitLab เรียกว่า Pull Request (PR) ซึ่ง team จะ review โค้ดก่อนว่า ok ไหมค่อย merge

เริ่มใช้ Git ตั้งแต่ต้น

# ตั้งค่าครั้งแรก
git config --global user.name "Chawanee"
git config --global user.email "chao@example.com"

# สร้าง repo ใหม่ใน folder ปัจจุบัน
git init

# หรือ clone repo ที่มีอยู่แล้วจาก GitHub
git clone https://github.com/username/my-project.git

Workflow พื้นฐาน: add, commit, push

ทุกวันของ developer วนซ้ำกับ 3 คำสั่งนี้

# ดูสถานะว่าไฟล์ไหนเปลี่ยนไปบ้าง
git status

# เพิ่มไฟล์เข้า staging area
git add index.html
git add .             # เพิ่มทุกไฟล์ที่เปลี่ยน

# commit พร้อม message
git commit -m "add login page"

# push ขึ้น GitHub
git push origin main

Branch Workflow ในทีม

ในทีมจริงๆ จะไม่ commit ลง main โดยตรงค่ะ จะแยก branch ออกมาก่อน

# สร้าง branch ใหม่และย้ายไปทันที
git checkout -b feature/add-payment

# ทำงาน commit ตามปกติ...
git add .
git commit -m "add payment form component"

# push branch ขึ้น GitHub
git push origin feature/add-payment

# กลับ main branch
git checkout main

# merge branch เข้า main (หลัง PR ผ่านแล้ว)
git merge feature/add-payment

ดึง code ล่าสุดจากทีม

# ดึง update ล่าสุดจาก remote
git pull origin main

# ดู history การ commit
git log
git log --oneline    # แบบย่อ

เมื่อเกิด Merge Conflict

Merge conflict เกิดขึ้นเมื่อสองคนแก้ไขไฟล์เดียวกันในบรรทัดเดียวกัน แล้ว Git ไม่รู้ว่าจะเอาของใครดี

<<<<<<< HEAD
const greeting = "สวัสดีค่ะ"    ← โค้ดของเรา
=======
const greeting = "Hello"       ← โค้ดของคนอื่น
>>>>>>> feature/update-greeting

วิธีแก้คือเปิดไฟล์ขึ้นมา เลือกว่าจะเอาของใคร (หรือรวมกัน) แล้วลบ marker พวก <<< === >>> ออก แล้วค่อย commit ใหม่

Merge conflict ฟังดูน่ากลัวตอนแรก แต่จริงๆมันเป็นแค่ Git บอกว่า "เฮ้ ต้องมาตัดสินใจเองนะ ฉันเลือกให้ไม่ได้" แก้ไปก็จบ ไม่ได้น่ากลัวอย่างที่คิดค่ะ

.gitignore ไฟล์ที่ไม่อยากส่งขึ้น Git

มีไฟล์บางอย่างที่ไม่ควร push ขึ้น GitHub เช่น ไฟล์ secret, node_modules, หรือไฟล์ build ที่ขนาดใหญ่มาก เราบอก Git ได้ผ่านไฟล์ชื่อ .gitignore

# .gitignore
node_modules/
.env
*.log
dist/
.DS_Store

GitHub vs GitLab vs Bitbucket

สำหรับมือใหม่แนะนำ GitHub ก่อนเลยค่ะ community ใหญ่ หาวิธีแก้ปัญหาได้ง่ายที่สุด

สรุป EP.3

• Git คือ version control ที่บันทึก snapshot ของโค้ดทุกครั้งที่ commit
• Workflow พื้นฐาน: add -> commit -> push
• Branch ช่วยให้ทำงานคู่ขนานโดยไม่ชน กัน
• Merge conflict ไม่ได้น่ากลัว แค่ต้องเลือกด้วยตัวเอง
• ห้าม push .env หรือ secret ขึ้น GitHub เด็ดขาด