
Designer ไม่รู้จัก Git ในปี 2026 = กำลังทำงานแบบที่โลกเลิกทำไปแล้ว . ไม่ได้พูดเกินจริง เดี๋ยวอธิบายให้ฟังว่าทำไม และสอนใช้ตั้งแต่ต้น —————————————————— 🔵 Git ค
Designer ไม่รู้จัก Git ในปี 2026 = กำลังทำงานแบบที่โลกเลิกทำไปแล้ว
.
ไม่ได้พูดเกินจริง
เดี๋ยวอธิบายให้ฟังว่าทำไม และสอนใช้ตั้งแต่ต้น
——————————————————
🔵 Git คืออะไร
——————————————————
Git คือระบบ version control
แปลตรงๆ คือมัน "จำ" ทุกการเปลี่ยนแปลงที่เกิดขึ้นในโปรเจกต์
.
ทุกครั้งที่แกบันทึกผ่าน Git
มันถ่ายรูปสถานะทั้งโปรเจกต์เก็บไว้เป็น checkpoint
แก rollback กลับไปจุดไหนก็ได้
แก branch ออกมาทดลองโดยไม่กระทบของจริง
แก merge งานของหลายคนเข้าด้วยกันโดยไม่ conflict
.
ไม่มีไฟล์ชื่อ final_v3_REAL_ใช้อันนี้นะ อีกต่อไป
——————————————————
🔵 ทำไม Designer ถึงต้องใช้ Git
——————————————————
เหตุผลจริงๆ ไม่ใช่แค่ตามกระแส
.
📌 1. เอกสาร Design System อยู่ใน repo
.
ถ้าแกทำ Design System จริงจัง
documentation ที่ดีไม่ได้อยู่แค่ใน Figma หรือ Notion
.
มันอยู่ใน repo เดียวกับ code
เพราะ dev ต้องอ่าน ต้องแก้ ต้องอัปเดตพร้อมกัน
ถ้าแกเข้า repo ไม่เป็น แกแตะ Design System จริงๆ ไม่ได้
แกได้แค่ทำ Figma แล้วฝากคนอื่น implement ให้
.
📌 2. Design Token อยู่ใน codebase
.
Token ที่แกตั้งใน Figma Variables
ถ้า export ออกมาเป็น JSON หรือ CSS variables แล้วใส่ใน repo
นั่นคือ single source of truth จริงๆ ของ Design System
.
การอัปเดต token ทุกครั้งคือการ commit ลง Git
ถ้าแกไม่รู้จัก Git แกต้องฝากให้ dev ทำให้ทุกครั้ง
แทนที่จะทำเองได้เลย
.
📌 3. Vibe Coder ที่ไม่ใช้ Git คือ Vibe Coder ที่ทำงานบนระเบิด
.
ตอนแก Vibe Code ด้วย AI
แก generate code ไป iterate ไป ปรับไป
วันนึงมัน break ทุกอย่าง แล้วแกจำไม่ได้ว่าแก้อะไรไปบ้าง
.
ถ้ามี Git แกแค่ rollback กลับไป commit ก่อนหน้า
ถ้าไม่มี แกนั่งไล่ debug เองตั้งแต่ต้น
.
Git คือ safety net ของ Vibe Coder
ไม่มีมันคือเดินไต่เชือกโดยไม่มีตาข่ายรองรับ
.
📌 4. ทำงานกับ dev เป็นภาษาเดียวกัน
.
ทีม dev ทุกทีมในโลกใช้ Git
ถ้าแกพูดว่า "ช่วย merge branch นี้ให้หน่อย" ได้
แกคือ designer ที่ทีม dev อยากทำงานด้วย
.
ถ้าพูดไม่ได้ แกก็คือคนที่ส่ง spec แล้วรอ
——————————————————
🔵 เริ่มใช้จริง สอนตั้งแต่ต้น
——————————————————
⚙️ Step 0 — ติดตั้ง
.
เริ่มจาก GitHub Desktop ก่อน ไม่ต้องแตะ terminal
ดาวน์โหลดที่ desktop.github.com
สมัคร GitHub ถ้ายังไม่มี
——————————————————
📖 Step 1 — รู้จัก concept หลัก 5 อย่าง
.
ก่อนใช้ต้องเข้าใจคำพวกนี้ก่อน ไม่งั้นทำตามขั้นตอนแล้วงง
.
▸ Repository (Repo)
คือโฟลเดอร์โปรเจกต์ที่ Git ดูแลอยู่
ทุก file ทุก change ในนั้น Git รู้หมด
มีได้สองแบบ — local (อยู่ในเครื่อง) กับ remote (อยู่บน GitHub)
.
▸ Commit
คือการ "บันทึกจุด" ในเวลา
เหมือนกดถ่ายรูปสถานะทั้งโปรเจกต์เก็บไว้
ทุก commit มี message อธิบายว่าทำอะไรไป
แกย้อนกลับมาจุดไหนก็ได้ในประวัติศาสตร์
.
▸ Branch
คือการแตก timeline ออกมาทำแบบ parallel
main branch คือ version ที่ใช้งานจริง
แกสร้าง branch ใหม่แล้วทดลองได้เลยโดยไม่กระทบ main
ถ้าดีค่อย merge กลับ ถ้าไม่ดีก็ลบทิ้ง
.
▸ Push / Pull
Push = เอา commit จากเครื่องแกขึ้น GitHub
Pull = ดึง commit ล่าสุดจาก GitHub มาที่เครื่องแก
ทำสองอย่างนี้สม่ำเสมอ = ไม่มีทางทำงานบน version เก่าโดยไม่รู้ตัว
.
▸ Clone
คือการ copy repo จาก GitHub มาที่เครื่องแกครั้งแรก
ทำครั้งเดียว แล้วใช้ Pull หลังจากนั้น
——————————————————
🛠️ Step 2 — สร้าง Repo ครั้งแรก
.
เปิด GitHub Desktop
กด "Create a New Repository on your hard drive"
ตั้งชื่อ เช่น design-system-docs
เลือก folder ที่จะเก็บ
กด Create Repository
.
แค่นี้แกมี repo แล้ว
Git กำลัง track ทุกอย่างในโฟลเดอร์นั้น
——————————————————
🛠️ Step 3 — Commit ครั้งแรก
.
สร้างไฟล์อะไรก็ได้ใน folder นั้น
เช่น README.md แล้วพิมพ์ว่า "Design System Documentation"
.
กลับมาที่ GitHub Desktop
แกจะเห็นไฟล์ที่เพิ่งสร้างโผล่ขึ้นมาใน Changes
ที่ช่อง Summary ด้านล่าง พิมพ์ว่า "init: เริ่มต้น design system docs"
กด Commit to main
.
ทำแบบนี้ทุกครั้งที่แกแก้ไขอะไรที่สำคัญ
อย่า commit ทุก save — commit เมื่อทำอะไรสักอย่างเสร็จเป็นชิ้น
——————————————————
🛠️ Step 4 — Push ขึ้น GitHub
.
กด Publish Repository ด้านบนขวา (ครั้งแรก)
หลังจากนั้นกด Push origin ทุกครั้งที่อยากซิงก์ขึ้น GitHub
.
ตอนนี้งานแกอยู่บน cloud แล้ว
เครื่องพัง ก็ pull กลับมาได้เหมือนเดิม
——————————————————
🛠️ Step 5 — สร้าง Branch ทดลองของ
.
กด Current Branch ด้านบน
กด New Branch
ตั้งชื่อ เช่น experiment-new-token-structure
กด Create Branch
.
ตอนนี้แกอยู่ใน branch ใหม่แล้ว
ทดลองได้เต็มที่ แก้ได้ โยนทิ้งได้
main ยังอยู่ครบไม่มีอะไรหาย
.
ถ้า experiment สำเร็จ
กด Create a Pull Request บน GitHub
ให้คนอื่น review แล้ว merge กลับ main
——————————————————
🔵 Commit Message ที่ดีเขียนยังไง
——————————————————
นี่คือสิ่งที่ designer มักข้ามและทำให้ทีม dev เกลียดที่สุด
.
❌ "update"
❌ "แก้แล้ว"
❌ "asdf"
.
✅ "update button component — เพิ่ม disabled state"
✅ "fix spacing token ใน card — จาก 8px เป็น 12px"
✅ "add dark mode variant สำหรับ navigation bar"
.
format ที่ดีคือ [action]: [อะไร] — [context ถ้ามี]
คนที่มาอ่าน 6 เดือนให้หลังจะขอบคุณแก
——————————————————
🔵 Workflow จริงของ Designer ที่ใช้ Git เป็น
——————————————————
.
เช้ามา → Pull ดึง update ล่าสุด
ทำงาน → แก้ไฟล์ตามปกติ
เสร็จ chunk นึง → Commit พร้อม message ชัดๆ
จบวัน → Push ขึ้น GitHub
ทดลองอะไรใหม่ → สร้าง Branch ก่อนเสมอ
ดีแล้ว → Pull Request → Merge
.
แค่นี้คือ 90% ของสิ่งที่ designer ต้องใช้จริงใน daily life
——————————————————
🔵 Figma ยังต้องใช้ไหม
——————————————————
ใช้อยู่ แต่ role มันชัดขึ้น
.
Figma = ที่ design และ communicate กับ stakeholder
Git = ที่จัดการ source of truth ของ code, token, และ documentation จริงๆ
.
สองอันนี้ไม่ได้แข่งกัน ทำงานคู่กัน
Designer ที่แกร่งในยุคนี้ต้องใช้ได้ทั้งสอง
——————————————————
🔵 สรุป
——————————————————
Git ไม่ใช่เรื่องของ developer อีกต่อไป
.
Designer ที่อยู่ใน Design System
Designer ที่แตะ Design Token
Designer ที่ Vibe Code ได้
Designer ที่อยากทำงานร่วมกับ dev ได้จริง
.
ทุกคนต้องรู้จัก Git
.
ไม่ใช่เพราะมันเท่
แต่เพราะมันคือภาษากลางของคนทำ product ในยุคนี้
.
แกไม่ต้องเป็นผู้เชี่ยวชาญ
แค่ใช้เป็นก็พาแกไปได้ไกลกว่า designer อีกหลายคน
.
.
.
#DesignLazyyy #Git #DesignSystem #Designer #VibeCoding #DesignToken #UIUXDesign #Figma #WebDevelopment #นักออกแบบไทย
Share this article




