Git คืออะไร และทำไมไม่ได้มีประโยชน์แค่กับงานพัฒนาซอฟต์แวร์
Git ไม่ได้มีไว้สำหรับ programmer อย่างเดียว แต่เป็นเครื่องมือช่วยเก็บประวัติการเปลี่ยนแปลงของงาน ทั้งโค้ด เอกสาร โน้ต คู่มือ และไฟล์ข้อความอื่น ๆ บทความนี้เป็นบทนำสำหรับคนทั่วไปก่อนเริ่มอ่านซีรีส์ Git tutorial
เวลาพูดถึง Git หลายคนจะนึกถึง programmer, source code, command line หรือหน้าจอดำ ๆ ที่ดูไม่ค่อยเป็นมิตรกับคนทั่วไป
แต่ถ้าตัดคำศัพท์เทคนิคออกก่อน แก่นของ Git เรียบง่ายกว่านั้นมากครับ Git คือเครื่องมือที่ช่วยให้เรารู้ว่าไฟล์เปลี่ยนไปอย่างไร เมื่อไร และเพราะอะไร
ถ้าคุณเคยมีไฟล์ชื่อประมาณนี้:
proposal-final.docxproposal-final-v2.docxproposal-final-new-real.docxproposal-final-use-this-one.docx
คุณเข้าใจปัญหาของ version control แล้ว โดยอาจยังไม่รู้ว่ามันมีชื่อเรียกแบบนี้
บทความนี้ตั้งใจเป็นบทแนะนำก่อนเข้าสู่ซีรีส์สอนใช้ Git ที่เคยเขียนไว้ ไม่ได้ตั้งใจสอนคำสั่งทั้งหมดในหน้าเดียว โดยเฉพาะสำหรับผู้อ่านที่มีพื้นฐานการใช้คอมพิวเตอร์และงานเอกสารทั่วไป แต่ยังไม่ใช่ developer หรือผู้เชี่ยวชาญด้านเทคนิค
สาระตั้งต้นก่อนเขียนเป็นบทความ
ก่อนจะอธิบายให้เป็นภาษาง่าย ผมสรุปแก่นของเรื่องไว้แบบนี้:
- Git คือ version control system หรือระบบติดตามการเปลี่ยนแปลงของไฟล์
- Git มีประโยชน์มากกับ source code เพราะ code เป็นไฟล์ข้อความที่เห็น diff ได้ชัด
- Git ก็มีประโยชน์กับงานเอกสาร โดยเฉพาะ Markdown, note, policy, checklist, SOP, runbook และเอกสารที่ต้อง review
- Git ไม่ใช่ backup แท้ ๆ และไม่ได้เหมาะกับไฟล์ทุกชนิดเท่ากัน
- สำหรับมือใหม่ สิ่งสำคัญที่สุดไม่ใช่จำคำสั่งเยอะ แต่คือเข้าใจว่า Git ช่วยเก็บประวัติ ทำให้ย้อนดูได้ และทำให้การคุยเรื่องงานมีหลักฐานมากขึ้น
Git ช่วยแก้ปัญหาอะไรในชีวิตจริง
ปัญหาที่ Git แก้ ไม่ใช่ปัญหาของ programmer อย่างเดียว
ลองนึกถึงงานทั่วไป:
- เขียน proposal แล้วอยากย้อนดูว่าลูกค้าขอเปลี่ยนอะไร
- แก้คู่มือ onboarding หลายรอบ แล้วไม่แน่ใจว่า version ไหนล่าสุด
- ทำ checklist ก่อนส่งงาน แล้วอยากรู้ว่าใครเพิ่มข้อไหนเข้ามา
- เขียน policy หรือ SOP แล้วต้องให้คนอื่น review ก่อนใช้จริง
- ทำเว็บไซต์หรือระบบเล็ก ๆ แล้วอยากรู้ว่าการแก้ครั้งไหนทำให้เกิดปัญหา
Git ช่วยด้วยการทำให้การเปลี่ยนแปลงมีประวัติ ไม่ใช่แค่มีไฟล์ล่าสุด
สิ่งที่ต่างจากการ copy ไฟล์เก็บไว้เองคือ Git ไม่ได้เก็บแค่ “ไฟล์อีกชุดหนึ่ง” แต่เก็บเป็นชุดเหตุการณ์ที่เราเรียกว่า commit แต่ละ commit ควรมีข้อความกำกับว่าเปลี่ยนอะไร เช่น “ปรับ scope proposal ให้ตรงกับ feedback ลูกค้า” หรือ “เพิ่ม checklist สำหรับตรวจเอกสารก่อนส่ง”
เมื่อเวลาผ่านไป ประวัตินี้จะกลายเป็นสมุดบันทึกการตัดสินใจของงานชิ้นนั้น
ทำไม Git ถึงสำคัญกับงานพัฒนาซอฟต์แวร์
สำหรับงานซอฟต์แวร์ Git สำคัญมาก เพราะ code เปลี่ยนตลอดเวลา และการเปลี่ยนเล็ก ๆ หนึ่งบรรทัดอาจทำให้ระบบทำงานต่างไปจากเดิม
Git ช่วยตอบคำถามที่สำคัญ เช่น:
- เมื่อวานเราแก้อะไรไปบ้าง
- บรรทัดนี้ถูกเพิ่มเข้ามาเมื่อไร
- ถ้า feature ใหม่ทำให้ระบบพัง เราควรย้อนดู commit ไหน
- งานของคนสองคนชนกันตรงไหน
- version ที่ปล่อยไปให้ผู้ใช้คือ commit ไหน
สำหรับทีมพัฒนา Git จึงไม่ได้เป็นแค่ที่เก็บไฟล์ แต่เป็นฐานของการทำงานร่วมกัน เช่น branch, pull request, code review, release และ CI/CD
แต่สำหรับบทความนี้ ผมไม่อยากให้คนเริ่มต้นรู้สึกว่าต้องเข้าใจทุกอย่างทันที ขอให้จำง่าย ๆ ก่อนว่า Git ทำให้ทีมเห็นประวัติเดียวกัน และคุยกันจากหลักฐานเดียวกัน แทนที่จะคุยจากความจำหรือไฟล์ที่ส่งต่อกันในแชต
แล้วงานเอกสารควรใช้ Git เมื่อไร
งานเอกสารไม่ได้ต้องใช้ Git ทุกกรณี
ถ้าเป็นไฟล์สั้น ๆ ที่เขียนครั้งเดียวจบ ใช้ Google Docs หรือ Microsoft Word ปกติก็เพียงพอ แต่ถ้าเอกสารเริ่มมีลักษณะเหล่านี้ Git จะเริ่มน่าสนใจ:
- มีการแก้หลายรอบ
- มีหลายคน review
- ต้องรู้ว่าใครเปลี่ยนอะไร
- เป็นเอกสารที่ใช้ซ้ำ เช่น SOP, runbook, checklist, policy หรือ template
- เป็นไฟล์ Markdown, text, config หรือเอกสารที่อ่าน diff ได้
- ต้องเชื่อมกับเว็บไซต์ เอกสารออนไลน์ หรือระบบ publish อัตโนมัติ
Git ทำงานได้ดีที่สุดกับไฟล์ข้อความ เพราะมันแสดงได้ชัดว่าเพิ่มบรรทัดไหน ลบบรรทัดไหน หรือแก้คำไหน ถ้าเป็นไฟล์ .docx, .pptx, รูปภาพ หรือไฟล์ออกแบบขนาดใหญ่ Git ยังเก็บประวัติได้ แต่การดูความต่างจะไม่ละเอียดเท่าไฟล์ text
พูดแบบ practical คือ ถ้าคุณยังใหม่กับ Git ให้เริ่มจากไฟล์ Markdown, note, checklist หรือเอกสาร plain text ก่อน จะเห็นประโยชน์เร็วกว่าเริ่มจากไฟล์ binary ขนาดใหญ่
ตัวอย่างงานที่ไม่ใช่ software แต่ใช้ Git ได้ดี
งานเอกสารหลายประเภทเหมาะกับ Git มากกว่าที่หลายคนคิด
ตัวอย่างเช่น:
README.mdสำหรับอธิบาย projectmeeting-notes.mdสำหรับสรุปประชุมที่ต้องย้อนดูได้proposal-outline.mdสำหรับร่างขอบเขตงานsecurity-policy.mdสำหรับ policy ที่ต้อง reviewonboarding-checklist.mdสำหรับรับคนใหม่เข้าทีมrunbook.mdสำหรับขั้นตอนปฏิบัติงานcontent-draft.mdสำหรับบทความหรือ newsletter
ข้อดีคือทุกไฟล์พวกนี้มีความเป็นข้อความสูง ทำให้ Git แสดงความเปลี่ยนแปลงได้ชัดมาก
ถ้าทีมใช้ Git กับเอกสารดี ๆ มันจะช่วยลดคำถามแบบ “ใครแก้อันนี้”, “ทำไมลบ section นี้”, “เวอร์ชันไหนล่าสุด”, หรือ “เอกสารที่ส่งลูกค้าอิงจากร่างไหน”
Git ไม่ใช่ backup และไม่ใช่เครื่องมือวิเศษ
จุดหนึ่งที่ต้องพูดตรง ๆ คือ Git ไม่ใช่ backup ที่สมบูรณ์
ถ้า repository อยู่บนเครื่องคุณเครื่องเดียว แล้วเครื่องพังหรือหาย Git ก็หายไปด้วย ดังนั้นถ้าเป็นงานสำคัญ ควรมี remote repository เช่น GitHub, GitLab, Gitea หรือ server ภายในทีม และยังควรมี backup ตามความเหมาะสม
อีกเรื่องคือ Git ไม่ได้ทำให้การจัดการเอกสารดีขึ้นเองโดยอัตโนมัติ ถ้า commit message อ่านไม่รู้เรื่อง หรือทุกคนโยนไฟล์ทุกอย่างลง repo เดียวกันแบบไม่มีขอบเขต ประวัติก็จะรกและดูยากได้เหมือนกัน
Git เป็นเครื่องมือที่ดีมาก แต่ต้องใช้ร่วมกับนิสัยที่ดี เช่น:
- commit เป็นช่วง ๆ
- เขียน commit message ให้สื่อความหมาย
- แยกงานเป็นก้อนเล็กพออ่านได้
- ไม่เก็บข้อมูลลับหรือรหัสผ่านลง repo
- ตกลงกับทีมว่าเอกสารไหนต้อง review ก่อน merge
ถ้าทำได้แค่นี้ Git จะเริ่มช่วยงานมากกว่าทำให้งานซับซ้อน
ถ้าไม่ใช่ programmer ควรเริ่มยังไง
ผมไม่แนะนำให้คนเริ่มต้นเปิดเอกสาร Git reference แล้วอ่านทุกคำสั่งตั้งแต่วันแรก มันหนักเกินไปและทำให้ Git ดูน่ากลัวโดยไม่จำเป็น
วิธีเริ่มที่เป็นมิตรกว่าคือ:
- เลือกโฟลเดอร์งานเล็ก ๆ หนึ่งชุด
- เลือกไฟล์ที่เป็นข้อความ เช่น note หรือ Markdown
- ใช้ Git เพื่อบันทึกประวัติเป็นช่วง ๆ
- ฝึกดูว่าเปลี่ยนอะไรไปบ้าง
- ฝึกเขียนข้อความบันทึกให้ตัวเองในอนาคตอ่านรู้เรื่อง
เป้าหมายแรกไม่ใช่ “ใช้ Git ให้เก่ง” แต่คือ “เลิกกลัวการเปลี่ยนแปลงของไฟล์”
ถ้าใช้ command line ยังดูน่ากลัว คุณอาจเริ่มจาก Git GUI หรือ editor ที่รองรับ Git ได้ เช่น VS Code, GitHub Desktop หรือเครื่องมืออื่นที่ทีมใช้อยู่ แต่ถึงใช้ GUI ผมยังแนะนำให้เข้าใจแนวคิดพื้นฐาน เช่น working directory, staging, commit และ history เพราะเครื่องมือหน้าตาสวยแค่ไหนก็ทำงานบนแนวคิดเดียวกัน
บทความ Git Good ควรอ่านเรียงอย่างไร
บทความนี้เป็นเหมือนหน้ารวมความเข้าใจก่อนเข้า tutorial เดิม ถ้าคุณอยากไปต่อ ผมแนะนำให้อ่านตามลำดับนี้:
เริ่มจาก Git คืออะไร, version control, status, add, commit, log และการใช้ Git กับเอกสาร
เหมาะเมื่อเริ่มทำงานหลายเรื่องพร้อมกัน หรือต้องทำงานกับคนอื่นผ่าน branch, remote และ pull request
เหมาะเมื่อทีมเริ่มต้องมีกติกาว่า branch, review, merge และ release ควรเดินอย่างไร
เหมาะเมื่อเริ่มสนใจ Git server, Gitea, automation และ pipeline ที่ทีมดูแลเอง
ถ้าคุณไม่ใช่ programmer ผมแนะนำให้อ่านตอนที่ 1 ก่อน แล้วหยุดทดลองกับเอกสารเล็ก ๆ สักชุดหนึ่ง ยังไม่ต้องรีบไปตอนที่ 4 เพราะบทความท้ายซีรีส์เริ่มแตะเรื่องระบบและ automation มากขึ้น
Checklist ก่อนตัดสินใจใช้ Git กับงานเอกสาร
ลองถามตัวเองก่อน:
- เอกสารนี้จะถูกแก้หลายรอบหรือไม่
- มีหลายคนต้อง review หรือไม่
- จำเป็นต้องรู้ประวัติการเปลี่ยนแปลงหรือไม่
- ไฟล์เป็น text หรือ Markdown ได้ไหม
- มีข้อมูลลับที่ไม่ควรเข้า repo หรือไม่
- ต้อง publish หรือ build เอกสารต่อหรือไม่
- ทีมมีคนดูแล repo และกติกาการใช้งานหรือไม่
ถ้าตอบว่า “ใช่” หลายข้อ Git อาจช่วยให้กระบวนการเอกสารนิ่งขึ้นมาก
แต่ถ้าเป็นเอกสารสั้น ๆ แก้คนเดียวครั้งเดียว หรือเป็นไฟล์ binary ที่ต้องแก้ผ่านโปรแกรมเฉพาะ Git อาจยังไม่ใช่เครื่องมือแรกที่ต้องใช้
สรุป
Git ไม่ใช่เรื่องของ programmer เท่านั้น แต่เป็นวิธีคิดเรื่องการเก็บประวัติของงาน
สำหรับงานซอฟต์แวร์ Git ช่วยให้ทีมเห็นว่า code เปลี่ยนอย่างไร ทำงานร่วมกันอย่างไร และ release อะไรออกไปเมื่อไร สำหรับงานเอกสาร Git ช่วยให้ note, policy, checklist, SOP, runbook และ content draft มีประวัติที่อ่านย้อนหลังได้
คุณไม่จำเป็นต้องเริ่มจากคำสั่งยาก ๆ หรือ workflow ใหญ่ ๆ เริ่มจากไฟล์ข้อความเล็ก ๆ หนึ่งชุด บันทึกการเปลี่ยนแปลงให้เป็นช่วง และฝึกเขียนข้อความ commit ให้ตัวเองในอนาคตอ่านเข้าใจ แค่นี้ก็เริ่มเห็นคุณค่าของ Git แล้ว
สุดท้าย ประโยชน์ของ Git ไม่ได้อยู่ที่มันทำให้เราดูเป็นสายเทคนิคมากขึ้น แต่อยู่ที่มันช่วยให้การเปลี่ยนแปลงไม่หายไปเงียบ ๆ และช่วยให้เราทำงานอย่างมีหลักฐานมากขึ้น
อ่านต่อที่เกี่ยวข้อง
- ถ้าอยากเริ่มจากศูนย์ อ่าน สอนใช้ Git ตอนที่ 1: Track Everything, Fear Nothing
- ถ้าเริ่มทำงานร่วมกับคนอื่น อ่าน สอนใช้ Git ตอนที่ 2: Branching Out, Collaborate Without Chaos