บทความนี้มาจากที่ผมอยากแนะนำ Front-end มือใหม่ให้รู้จักกับ Git Workflow เพื่อนำไปประยุกต์ใช้ในการทำงานจริง เลยตั้งใจจะเขียนเป็นซีรีส์ "Git Workflow สำหรับ Front-End Dev จาก Zero สู่ Hero ในทีม" และนี่คือบทความแรกครับ

เราทุกคนคงเคยรู้สึกเสียวสันหลังวาบกันมาแล้ว จังหวะที่คุณเพิ่งจะปล่อยฟีเจอร์ใหม่สุดเจ๋งขึ้น Production ทุกอย่างดูสวยงาม แต่หนึ่งชั่วโมงต่อมา รายงานบั๊กกลับหลั่งไหลเข้ามา ส่วนอื่นของเว็บไซต์ที่ไม่เกี่ยวข้องกันเลยกลับพังซะงั้น หรืออาจจะเป็นสถานการณ์สุดคลาสสิก

คุณกับเพื่อนร่วมทีมดันไปแก้ไฟล์ CSS ไฟล์เดียวกัน พอโค้ดถูกรวมเข้าด้วยกัน layout ก็ระเบิดเละเทะ แล้วคุณก็ต้องใช้เวลาอีกหลายชั่วโมงไล่โค้ดทีละบรรทัด ถามว่า "ใครแก้ อะไร เมื่อไหร่?"

ถ้าคุณเป็น Front-End Developer และความสัมพันธ์ของคุณกับ Git มีแค่การพิมพ์ git add ., git commit -m "update", และ git push วนไปวนมา คุณก็ไม่ต่างอะไรจากการขับรถสปอร์ตสมรรถนะสูง แต่ไม่เคยเปลี่ยนจากเกียร์หนึ่งเลย คุณกำลังพลาด "หัวใจ" ที่ทำให้ Git เป็นเครื่องมือที่ขาดไม่ได้ในการพัฒนาซอฟต์แวร์ยุคใหม่ มันไม่ใช่แค่ที่ backup code บนคลาวด์ แต่มันคือระบบที่ออกแบบมาเพื่อสร้างความชัดเจน ความปลอดภัย และช่วยให้คุณทำงานร่วมกับคนอื่นได้โดยไม่เกิดความโกลาหล

มาเปลี่ยนเกียร์แล้วทำความเข้าใจเครื่องมือที่เราใช้งานกันอยู่ให้ลึกซึ้งกว่าเดิมกันครับ

The 3 Trees เข้าใจก่อนว่าโค้ดของเราอยู่ที่ไหน

ก่อนที่คุณจะใช้ Git ได้อย่างเต็มประสิทธิภาพ คุณต้องเลิกมองว่ามันเป็นแค่ปุ่ม Save ปุ่มเดียว ลองจินตนาการว่าโปรเจกต์ของคุณมี 3 พื้นที่ที่แตกต่างกัน การเข้าใจการเดินทางของไฟล์ผ่านโซนเหล่านี้คือกุญแจสำคัญสู่พลังของ Git

1. Working Directory (พื้นที่ทำงาน): นี่คือโต๊ะทำงานของคุณ มันอาจจะรก อาจจะวุ่นวาย และเป็นที่ที่งานทุกอย่างเกิดขึ้นจริง ไฟล์ทุกไฟล์ที่คุณสร้าง แก้ไข หรือลบใน Code Editor ของคุณจะอยู่ที่นี่ มันคือสนามเด็กเล่นของคุณที่ยังไม่มีการบันทึกใดๆ
2. Staging Area (พื้นที่เตรียมการ หรือ "Index"): ให้คิดว่านี่คือ "ถาดเอกสารพร้อมรีวิว" บนโต๊ะทำงานของคุณ หลังจากที่คุณทำงานกับไฟล์บางส่วนเสร็จสิ้นและพอใจกับการเปลี่ยนแปลงที่สมเหตุสมผลแล้ว (เช่น สร้างฟอร์มติดต่อเราเสร็จแล้ว) คุณไม่ได้โยนทุกอย่างเข้าตู้เก็บเอกสารทันที แต่คุณจะเลือกเฉพาะไฟล์ที่เกี่ยวข้องอย่างระมัดระวังแล้ววางมันลงในถาดนี้ นี่คือสิ่งที่ git add ทำครับ มันคือการส่งสัญญาณว่า "การเปลี่ยนแปลงชุดนี้เสร็จสมบูรณ์และพร้อมที่จะถูกบันทึกแล้ว"
3. Repository (พื้นที่จัดเก็บ หรือ .git directory): นี่คือ "ตู้เก็บเอกสาร" ที่เป็นทางการและถาวร เมื่อคุณรันคำสั่ง git commit คุณกำลังนำทุกอย่างที่อยู่ในถาดเตรียมการ (Staging Area) มาถ่ายรูปสแนปช็อต แปะป้ายที่อธิบายรายละเอียดชัดเจน (นั่นคือ commit message ของคุณ) แล้วนำไปเก็บเข้าแฟ้มอย่างถาวร Repository ก็คือประวัติศาสตร์ทั้งหมดของสแนปช็อตที่ถูกติดป้ายไว้อย่างเป็นระเบียบนั่นเอง

เมื่อมองแบบนี้ คุณจะเห็นว่า git add ไม่ใช่แค่ "เพิ่มทุกอย่าง" แต่มันคือการกระทำที่ "ตั้งใจ" จัดองค์ประกอบของสแนปช็อต และ git commit ก็ไม่ใช่แค่ "เซฟ" แต่มันคือการบันทึกสแนปช็อตที่จัดเตรียมไว้อย่างดีแล้วนั้นลงในประวัติศาสตร์อย่างถาวรพร้อมข้อความที่มีความหมาย

ศิลปะแห่ง Commit Message ข้อความถึงตัวเองในอนาคต

ถ้า Repository คือหนังสือประวัติศาสตร์ของโปรเจกต์ Commit Message ก็คือชื่อบทแต่ละบท คุณอยากอ่านหนังสือที่ทุกบทชื่อว่า "อัปเดต" หรือหนังสือที่มีชื่อบทชัดเจนและสื่อความหมาย?

Commit แบบ git commit -m "fix" นั้นไร้ประโยชน์ต่อทีมและต่อตัวคุณเองในอนาคต มันไม่ได้บอกอะไรเลย แก้ไขอะไร? ทำไมมันถึงพัง?

การนำมาตรฐานง่ายๆ อย่าง Conventional Commits มาใช้ จะสามารถเปลี่ยนประวัติศาสตร์โปรเจกต์ที่ยุ่งเหยิงให้กลายเป็น Log ที่อ่านรู้เรื่องได้ โครงสร้างของมันเรียบง่ายมาก: type: description

• feat: สำหรับฟีเจอร์ใหม่
  • feat: add reCAPTCHA to the registration form
• fix: สำหรับการแก้บั๊ก
  • fix: correct button alignment issue on Safari mobile
• docs: สำหรับการแก้ไขเอกสารประกอบ (Documentation)
  • docs: update readme with environment variable instructions
• style: สำหรับการแก้สไตล์ของโค้ดที่ไม่ได้กระทบ Logic (เช่น จัด Format, เพิ่ม/ลบ space)
  • style: format CSS files with Prettier
• refactor: สำหรับการปรับโครงสร้างโค้ดที่ไม่ได้แก้บั๊กหรือเพิ่มฟีเจอร์
  • refactor: simplify user data fetching logic

เขียน Commit message ให้ดีตามรูปแบบของ Conventional commits

Commit message เป็นข้อความที่อธิบายการเปลี่ยนแปลงที่ทำในโค้ด มันมีความสำคัญมากในการติดตามการเปลี่ยนแปลงที่เกิดขึ้นในแต่ละเวอร์ชันของซอฟต์แวร์ ช่วยให้นักพัฒนาคนอื่น ๆ สามารถเข้าใจการเปลี่ยนแปลงที่เกิดขึ้นได้ง่ายขึ้น และสามารถย้อนกลับไปแก้ไขหรืออัปเดตโค้ดได้อย่างถูกต้อง

Snappytux: Where Code Meets Board Games & Plant-Based StyleArnon Kijlerdphon

ประโยชน์ของมันเห็นได้ทันที ประวัติโปรเจกต์ของคุณจะค้นหาง่าย ทุกคนสามารถเข้าใจวิวัฒนาการของโปรเจกต์ได้อย่างรวดเร็ว และคุณยังสามารถสร้าง CHANGELOG (รายการการเปลี่ยนแปลง) โดยอัตโนมัติได้อีกด้วย

เครื่องมือคู่ใจ 3 คำสั่งที่จะช่วยให้คุณไม่หัวเสีย

นอกเหนือจาก add และ commit แล้ว 3 คำสั่งนี้คือเพื่อนซี้ที่จะช่วยให้คุณสำรวจโปรเจกต์ของคุณได้อย่างสบายใจ

• git status: คือ GPS ประจำโปรเจกต์ของคุณ มันตอบคำถามสำคัญๆ เช่น "ตอนนี้ฉันอยู่ที่ไหน? ฉันแก้ไขไฟล์อะไรไปบ้าง? มีอะไรอยู่ใน Staging Area ที่พร้อมจะ commit แล้ว?" ใช้คำสั่งนี้บ่อยๆ ครับ มันคือแหล่งข้อมูลจริงหนึ่งเดียวของคุณ
• git diff: คือเกม "จับผิดภาพ" ขั้นเทพสำหรับโค้ดของคุณ มันจะแสดงให้เห็นการเปลี่ยนแปลงแบบบรรทัดต่อบรรทัดในไฟล์ที่คุณยังไม่ได้ stage เหมาะสุดๆ สำหรับการรีวิวงานของตัวเองอีกครั้งก่อนจะรัน git add
• git log: คือสมุดบันทึกเรื่องราวของโปรเจกต์ ในรูปแบบพื้นฐานที่สุด มันจะแสดงประวัติการ commit ทั้งหมด แต่เวอร์ชันที่ทรงพลังกว่าที่ผมใช้ทุกวันคือ git log --oneline --graph ซึ่งจะแสดงประวัติแบบย่อพร้อมเห็นภาพกิ่งก้านสาขา ซึ่งจะมีประโยชน์อย่างยิ่งเมื่อเราเริ่มพูดถึงเรื่อง Branch

บทสรุป: ไม่ใช่แค่งาน แต่คือการปรับทัศนคติ

Git เป็นมากกว่าภาระงานที่ Tech Lead สั่งให้ทำ แต่มันคือตาข่ายนิรภัย (Safety Net), กรอบการทำงานร่วมกัน (Collaboration Framework), และไทม์แมชชีนในเครื่องมือเดียว การเข้าใจขั้นตอนการทำงานจาก Working Directory ไปสู่ Repository และการเขียน Commit Message อย่างใส่ใจ ไม่ใช่เป็นเพียงการเซฟโค้ด แต่คือการสร้างประวัติการทำงานที่เป็นมืออาชีพและน่าเชื่อถือ

การเรียนรู้พื้นฐานเหล่านี้ให้แม่นยำคือบันไดก้าวแรก มันจะเปลี่ยนมุมมองของคุณและเตรียมคุณให้พร้อมสำหรับหัวใจที่แท้จริงของการทำงานร่วมกันเป็นทีม

ในบทความหน้า เราจะมาสำรวจแนวคิดที่สำคัญที่สุดสำหรับการทำงานบนฟีเจอร์ต่างๆ โดยไม่เดินชนกับเพื่อนร่วมทีม นั่นก็คือเรื่องของ Branching ครับ