สอนใช้ Git ตอนที่ 1: Track Everything, Fear Nothing

บทความนี้เป็นตอนที่ 1 ของซีรีส์สอนใช้ Git ที่มีทั้งหมด 4 ตอน ที่จะค่อย ๆ พาไปจากพื้นฐานการเก็บประวัติไฟล์ ไปจนถึงการออกแบบ workflow และ self-hosted CI/CD ด้วย Gitea

ถ้าคุณเคยทำไฟล์สำคัญหาย เผลอบันทึกทับเอกสารผิดเวอร์ชัน หรือย้อนกลับไปดูไม่ได้ว่าเมื่อวานแก้อะไรไปบ้าง คุณไม่ได้มีปัญหาคนเดียว เรื่องพวกนี้เกิดขึ้นกับคนทำงานแทบทุกสาย ไม่ว่าจะเป็น developer, คนเขียนเอกสาร, นักวิจัย, content team หรือคนที่ดูแล project file หลายชุดพร้อมกัน

นี่คือจุดที่ Git เข้ามาช่วยได้ และเหตุผลที่ผมคิดว่า Git ไม่ควรถูกมองว่าเป็นเครื่องมือของ programmer อย่างเดียว

ในซีรีส์นี้ ผมจะใช้เรื่องของ Maya เป็นตัวเดินเรื่อง Maya เป็น project manager ที่เขียนโค้ดได้บ้าง ดูแลทั้ง product wiki และ web app ของทีม วันหนึ่งเธอเผลอทำไฟล์สรุป requirement เวอร์ชันล่าสุดหายไปพร้อมกับการแก้ไขเกือบหนึ่งสัปดาห์ หลังจากนั้นเธอเริ่มมองหาเครื่องมือที่ช่วยให้ “ย้อนเวลาได้” กับทุกไฟล์ที่สำคัญ และนั่นคือจุดเริ่มต้นของ Git

Git คืออะไร แบบไม่ต้องเริ่มจากศัพท์ยาก

ถ้าพูดแบบเรียบง่าย Git คือระบบ version control หรือระบบที่ช่วยติดตามการเปลี่ยนแปลงของไฟล์ตามเวลา

คำว่า version control ฟังดูเทคนิค แต่จริง ๆ แนวคิดมันตรงไปตรงมามาก:

1. มันช่วยจำว่าไฟล์เปลี่ยนจากอะไรไปเป็นอะไร
2. มันช่วยให้คุณบันทึกเป็นช่วง ๆ แบบมีประวัติ
3. มันช่วยให้ย้อนกลับไปดูหรือกู้เวอร์ชันก่อนหน้าได้

ในเอกสารของ Git เอง Git อธิบายตัวเองในฐานะระบบที่เก็บ snapshot ของสถานะไฟล์ในแต่ละช่วง ไม่ได้มองเป็นแค่รายการ diff แบบลอย ๆ เพราะฉะนั้นเวลาคุณ commit คุณกำลังบันทึกภาพรวมของงานในจุดนั้นไว้

สิ่งสำคัญคือ Git ใช้กับไฟล์ได้หลายประเภท แม้ในทางปฏิบัติจะทำงานได้ดีที่สุดกับไฟล์ text เช่น code, Markdown, config หรือเอกสารที่เป็น plain text แต่ต่อให้คุณเริ่มจากโน้ต, research notes หรือไฟล์เอกสารประกอบงาน Git ก็ยังช่วยให้กระบวนการทำงานเป็นระบบขึ้นได้มาก

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

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

เริ่มติดตั้งและตั้งค่าครั้งแรก

หลังจากติดตั้ง Git แล้ว สิ่งแรกที่ควรทำคือกำหนดชื่อและ email ที่จะติดไปกับ commit ของคุณ

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

สองบรรทัดนี้สำคัญ เพราะทุก commit จะมี metadata หรือข้อมูลกำกับว่าใครเป็นคนบันทึกการเปลี่ยนแปลงนั้น

ถ้าจะเช็กว่าตอนนี้ Git เวอร์ชันอะไร หรือ config ถูกตั้งไว้หรือยัง คุณใช้ได้แบบนี้

git --version
git config --list

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

อีกเรื่องที่มือใหม่ชอบกังวลคือ “ต้องตั้งค่าอะไรเพิ่มไหม” คำตอบคือยังไม่จำเป็นต้องรีบตั้งทุกอย่างในวันแรก คุณยังไม่ต้องรู้เรื่อง advanced alias, signing key หรือ custom diff driver ก็ได้ สิ่งที่สำคัญกว่ามากคือเริ่มใช้ Git เป็นนิสัยก่อน แล้วค่อยปรับแต่งเมื่อคุณรู้แล้วว่าตัวเองใช้งานแบบไหนบ่อยที่สุด

ถ้าจะมีอีกสิ่งที่ควรรู้เร็วหน่อย มันคือ repo หนึ่งชุดควรมีขอบเขตที่สมเหตุสมผล อย่าโยนทุกอย่างในชีวิตลง Git ก้อนเดียว เช่น เอกสารงานหนึ่งชุดหรือโปรเจกต์หนึ่งตัวควรมี repo ของตัวเอง แบบนี้ประวัติจะอ่านง่ายและดูแลง่ายกว่าการเอาทุกอย่างมาปนกัน

หลักคิดนี้สำคัญมากสำหรับคนเริ่มต้น เพราะ repo ที่เล็กและชัดจะช่วยให้คุณเข้าใจได้เร็วว่า Git กำลังติดตามอะไรอยู่ และประวัติชุดไหนเป็นของงานอะไร ถ้าทุกอย่างถูกรวมกันตั้งแต่ต้น การอ่าน status, log และ diff จะยากขึ้นโดยไม่จำเป็น

ทำความเข้าใจ 3 สถานะหลักของ Git

ส่วนที่ทำให้มือใหม่งงที่สุดมักไม่ใช่คำสั่ง แต่เป็น mental model ว่าตอนนี้ไฟล์ของเราอยู่ตรงไหนในระบบของ Git

ถ้าให้สรุปแบบใช้งานจริง Git มี 3 พื้นที่หลักที่ควรรู้จัก:

1. Working directory
2. Staging area
3. Repository

Working directory คือไฟล์ที่คุณกำลังแก้อยู่จริงบนเครื่อง, Staging area คือพื้นที่เตรียมส่งขึ้น commit, Repository คือประวัติที่ถูกบันทึกแล้ว

ถ้าจะเปรียบเทียบแบบง่าย:

• Working directory คือโต๊ะทำงาน
• Staging area คือถาดเอกสารที่คุณเลือกแล้วว่าจะส่ง
• Repository คือแฟ้มเก็บงานถาวร

พอเข้าใจภาพนี้ คำสั่งพื้นฐานจะเริ่มสมเหตุสมผลขึ้นทันที เพราะ git add ไม่ได้แปลว่า “บันทึกถาวรแล้ว” แต่มันแปลว่า “เลือกสิ่งนี้ไปไว้ใน staging ก่อน”

มือใหม่จำนวนมากพลาดตรงนี้ เพราะคิดว่าแก้ไฟล์แล้ว Git น่าจะจำทุกอย่างให้อัตโนมัติ แต่จริง ๆ Git ตั้งใจให้คุณมีจังหวะ “คัดเลือก” ก่อนบันทึก เพื่อให้หนึ่ง commit เป็นหน่วยความคิดที่ชัดขึ้น ไม่ใช่กองการเปลี่ยนแปลงมั่ว ๆ ที่เกิดจากคุณทำหลายอย่างในคราวเดียว

นี่เป็นเหตุผลว่าทำไม commit ที่ดีมักไม่ใหญ่เกินไป ถ้าคุณแก้ทั้ง typo, เพิ่ม section ใหม่, เปลี่ยนโครงเอกสาร และลบไฟล์เก่าในรอบเดียว เวลาย้อนกลับมาดูคุณจะอ่านยากมาก แต่ถ้าแยกเป็นรอบตามเจตนา งานจะสะอาดขึ้นทันที

คำสั่งพื้นฐานที่คุณใช้บ่อยที่สุด

สมมติ Maya มีโฟลเดอร์ชื่อ product-wiki และอยากเริ่มติดตามไฟล์ทั้งหมดด้วย Git

cd product-wiki
git init

git init คือการสร้าง Git repository ใหม่ในโฟลเดอร์นั้น

จากนั้นถ้า Maya สร้างไฟล์ README.md และแก้โน้ต requirement แล้วอยากดูสถานะ:

git status

คำสั่งนี้สำคัญมาก เพราะมันบอกว่ามีอะไรถูกแก้, อะไรยังไม่ถูก track, และอะไรพร้อม commit แล้ว

ถ้าอยากเอาไฟล์เข้า staging:

git add README.md
git add notes.md

หรือถ้าอยาก add ทั้งหมดในรอบนั้น:

git add .

เมื่อเลือกไฟล์เสร็จแล้ว ค่อยบันทึกด้วย commit

git commit -m "Add initial project notes and README"

หลังจากนั้นถ้าอยากดูประวัติ:

git log

หรือแบบอ่านง่ายขึ้น:

git log --oneline

สรุป daily loop ที่สำคัญที่สุดของ Git สำหรับมือใหม่คือ:

git status
git add ...
git commit -m "Describe what changed"

ถ้าคุณอยากเห็นให้ชัดขึ้นว่ากำลังจะบันทึกอะไร คำสั่งที่ควรเริ่มใช้คู่กับชุดนี้คือ git diff และ git diff --staged

git diff
git diff --staged

คำสั่งแรกช่วยให้เห็นการเปลี่ยนแปลงที่ยังไม่ได้ถูก stage ส่วนคำสั่งที่สองช่วยให้เห็นสิ่งที่พร้อมจะถูก commit แล้ว นิสัยเล็ก ๆ นี้ช่วยลดโอกาส commit สิ่งที่ไม่ตั้งใจ เช่น โน้ตที่ยังไม่เสร็จหรือการแก้หลายเรื่องปนกันได้มาก

ถ้าจะให้ผมแนะนำหนึ่งนิสัยที่คุ้มที่สุดสำหรับช่วงเริ่มต้น มันคือการรัน git status บ่อย ๆ เพราะคำสั่งนี้เหมือนหน้าจอสรุปสถานะของคุณ มันช่วยให้คุณไม่หลงว่าตอนนี้อะไรเปลี่ยน อะไรยังไม่ถูก track และอะไรพร้อมจะถูกบันทึกแล้ว

พอคุณเริ่มคล่องขึ้น git log --oneline ก็จะกลายเป็นคำสั่งคู่กัน เพราะ status ช่วยบอกปัจจุบัน ส่วน log ช่วยบอกอดีต สองอย่างนี้รวมกันทำให้คุณเริ่ม “เห็นเวลา” ใน repo ของตัวเองชัดขึ้น

ตัวอย่างจริง: ใช้ Git กับเอกสาร ไม่ใช่แค่โค้ด

ลองนึกภาพว่าคุณมีโฟลเดอร์สำหรับ research notes, project plan และ draft บทความ ถ้าไม่มี Git เวลาคุณแก้ไฟล์คุณอาจได้ชื่อแบบ

• proposal-final.docx
• proposal-final-final.docx
• proposal-final-real.docx

ปัญหาคือชื่อไฟล์ไม่ได้บอกว่า “ทำไม” ถึงมีการเปลี่ยนแปลง แต่ Git บอกได้ เพราะ commit message คือคำอธิบายเชิงเหตุผล

Maya เริ่มจาก tracking ไฟล์ text ของทีมก่อน เช่น

• README.md
• requirements.md
• meeting-notes.md

ทุกครั้งที่มีความคืบหน้า เธอ commit พร้อมข้อความที่มีความหมาย เช่น

git commit -m "Clarify scope for product wiki MVP"
git commit -m "Add stakeholder meeting notes from 17 April"

แบบนี้ย้อนดูทีหลังจะรู้ทันทีว่าแต่ละรอบเปลี่ยนอะไร ไม่ใช่แค่เห็นว่าไฟล์ถูกเซฟอีกครั้งหนึ่ง

แน่นอนว่า Git ไม่ได้แทน backup ทุกอย่าง โดยเฉพาะถ้าคุณเก็บไฟล์ไบนารีขนาดใหญ่หรือไฟล์ที่มีรูปแบบซับซ้อนมาก แต่สำหรับงานจำนวนมากในโลกจริง เช่น spec, notes, docs, content draft, config และ source code มันช่วยยกระดับวิธีทำงานได้ทันทีตั้งแต่วันแรกที่เริ่ม

ตรงนี้ผมอยากพูดแบบแฟร์ ๆ ว่า ถ้าคุณใช้ไฟล์อย่าง .docx, .pptx หรือ asset ไบนารีขนาดใหญ่ Git ยังใช้ได้ แต่ประสบการณ์จะไม่ลื่นเท่ากับไฟล์ text เพราะการดู diff และการ merge จะจำกัดกว่า ดังนั้นถ้าจะเริ่มให้เห็นคุณค่าก่อน ผมแนะนำให้เริ่มกับ Markdown, text note, config หรือ source code ก่อน จะเห็นผลชัดที่สุด

เหตุผลไม่ใช่เพราะไฟล์แบบอื่น “ไม่ดีพอ” แต่เพราะ Git แสดงประโยชน์ได้เต็มกว่ากับสิ่งที่เราอ่านความเปลี่ยนแปลงได้ตรง ๆ เมื่อคุณเปิด diff แล้วเห็นว่ามีการเพิ่มย่อหน้าไหน ลบบรรทัดไหน หรือแก้ config จุดไหน คุณจะเริ่มเข้าใจ version control แบบจับต้องได้กว่าการเห็นเพียงว่าไฟล์หนึ่งถูกแทนด้วยอีกไฟล์หนึ่ง

ความผิดพลาดที่เจอบ่อยที่สุด

อย่างแรกคือ “ลืม commit” หลายคนแก้งานทั้งวันแต่ไม่ commit เป็นช่วง ๆ ทำให้สุดท้ายมีการเปลี่ยนแปลงก้อนใหญ่มากจนอ่านไม่ออก

อย่างที่สองคือ commit message แย่มาก เช่น

git commit -m "update"
git commit -m "fix"
git commit -m "work"

ข้อความแบบนี้แทบไม่ช่วยอะไรเวลาเปิดย้อนหลัง

ทางที่ดีกว่าคือบอกให้ชัดว่าเปลี่ยนอะไรและเพื่ออะไร เช่น

git commit -m "Update onboarding notes for new team members"
git commit -m "Fix typo in release checklist"
git commit -m "Add missing acceptance criteria to feature spec"

ผมมองว่า commit message ที่ดีไม่ต้องยาวมาก แต่ต้องช่วยให้ “ตัวคุณในอนาคต” เข้าใจได้ว่าในรอบนั้นเกิดอะไรขึ้น

ถ้ายังคิดไม่ออกว่าจะเขียนแบบไหนดี ให้ลองใช้โครงง่าย ๆ ว่า “ทำอะไร” และ “เพื่ออะไร” เช่น

• Add onboarding checklist for new editors
• Clarify login flow to match latest stakeholder feedback

แค่นี้ประวัติของคุณก็จะอ่านง่ายขึ้นมากแล้ว

ถ้าคุณยังไม่ชินกับการ commit บ่อย ลองตั้งกติกาเล็ก ๆ ให้ตัวเอง เช่น ทุกครั้งที่จบหนึ่งความคิด, จบหนึ่ง section หรือจบหนึ่ง task ย่อย ให้ถามตัวเองว่า “รอบนี้ควร commit หรือยัง” พอทำไปสักพัก การบันทึกเป็นช่วงจะกลายเป็นธรรมชาติเอง

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

สรุปสั้น ๆ ก่อนจบตอนแรก

ถ้าคุณเพิ่งเริ่ม ผมอยากให้จำแค่สามเรื่องนี้ก่อน

• Git ใช้ติดตามการเปลี่ยนแปลงของไฟล์ ไม่ได้มีไว้สำหรับ code อย่างเดียว
• สามสถานะสำคัญคือ working directory, staging area และ repository
• วงจรพื้นฐานของคุณคือ status → add → commit

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

ถ้าคุณอ่านมาถึงตรงนี้แล้วรู้สึกว่า Git ยังมีศัพท์เยอะอยู่ ผมอยากให้มองว่าหน้าที่ของตอนแรกไม่ใช่ทำให้คุณเก่ง Git ทันที แต่ทำให้คุณมี mental model ที่ถูกต้องก่อนว่าไฟล์เปลี่ยนอย่างไร ถูกเลือกอย่างไร และถูกบันทึกอย่างไร เมื่อภาพนี้ชัด คำสั่งอื่น ๆ ในอนาคตจะไม่ลอย

สิ่งที่สำคัญที่สุดจึงไม่ใช่การจำคำสั่งให้ได้มากที่สุด แต่คือการเริ่มใช้ Git กับงานจริงของตัวเองสักชุดหนึ่ง แล้วฝึกดู status, diff, add และ commit ให้คล่อง เพราะเมื่อคุณเห็นประวัติของงานตัวเองเริ่มเป็นระเบียบ คุณจะเข้าใจเองว่าทำไมคนจำนวนมากถึงไม่อยากกลับไปใช้วิธีตั้งชื่อไฟล์ว่า final-final-v2 อีกต่อไป

ถ้าจะเริ่มวันนี้เลย ให้เลือกโฟลเดอร์งานเล็ก ๆ สักหนึ่งชุด เปิด git init แล้วลอง commit รอบแรกให้ได้ ประสบการณ์จริงหนึ่งครั้งจะสอนคุณได้มากกว่าการอ่านทฤษฎีเพิ่มอีกหลายหน้า

และเมื่อคุณเริ่มเห็นประวัติของงานตัวเองชัดขึ้น ความกลัวเรื่องพลาด, ลืม, หรือย้อนกลับไม่ได้จะค่อย ๆ ลดลงเองตามธรรมชาติ

นั่นคือจุดเริ่มต้นที่แท้จริงของการใช้ Git อย่างมีความหมายในงานประจำวัน

เริ่มเล็ก เริ่มจริง และเริ่มสม่ำเสมอ จะเห็นผลเร็วที่สุดเสมอ

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

แหล่งอ้างอิง

• Git Book: Getting Started
• Git Book: First-Time Git Setup
• Git Reference