Git คืออะไร?
Git คือ Version Control ประเภทหนึ่ง
สำหรับการพัฒนา Software สิ่งหนึ่งที่สำคัญที่ขาดไม่ได้คือ Version Control หรือบางคนอาจจะเรียกว่า Source Control ซึ่งในปัจจุบันมีหลากหลายแบบให้เลือกใช้งานไม่ว่าจะเป็น SVN, Mercurial หรือ Git
Version Control ถือเป็นเครื่องมือที่ขาดไม่ได้เลยสำหรับการพัฒนาซอฟต์แวร์ ไม่ว่าจะเป็นนักพัฒนาแพลตฟอร์มไหนก็ตาม เพราะมันคือสิ่งที่ทำให้เรามั่นใจได้ว่า สิ่งที่เราได้ทุ่มเทพัฒนาขึ้นมาจะไม่สูญหายไปกับการกระชากของกระแสไฟเพียงครั้งเดียว อีกทั้งยังเป็นเหมือนสมุดบันทึกที่คอยบันทึกเรื่องราวที่เกิดขึ้นในกระบวนการพัฒนาได้เป็นอย่างดี ถึงแม้ว่าเราจะรู้ว่ามันมีประโยชน์มากมายแต่หากเราไม่รู้จักวิธีการใช้งานย่อมไม่สามารถใช้ความสามารถของมันได้เต็มที่
Version Control หรือเรียกกันสั้น ๆ ว่า VC นั้นแบ่งออกเป็นสองประเภทหลักคือ
- Centralized Version Control คือการเก็บรวบรวมข้อมูลไว้ที่ส่วนกลางที่เดียว โดยจำเป็นต้องมี Server กลางสำหรับเก็บข้อมูล Source Code ต่าง ๆ เพื่อใช้งานร่วมกัน เมื่อมีการ Commit เกิดขึ้น ข้อมูลจะถูกส่งเข้าไปเก็บที่ Server กลาง ทำให้ทุกคนในทีมจะเห็นการเปลี่ยนแปลงโดยทันที Version Control ในกลุ่มนี้ที่ได้รับความนิยมในปัจจุบันเช่น TFVC และ SVN เป็นต้น
- Distribute Version Control คือ Version Control ที่การเก็บข้อมูลของ Source Code แยกต่างหากจากส่วนกลาง โดยหลักการแล้วคือการเก็บข้อมูลไว้ที่เครื่องของนักพัฒนาแต่ละคน แต่ก็จำเป็นต้องมีสถานที่เก็บที่เป็นส่วนกลางเพื่อให้ทุกคนใช้งานร่วมกัน หรือที่เรียกกันติดปากว่า Central Repository เมื่อนักพัฒนาทำการ Stage งานที่ทำเสร็จแล้วข้อมูลจะถูกจัดเก็บลงในฐานข้อมูลในเครื่องก่อนเป็นอันดับแรก และจะอัพเดรตไปยังฐานข้อมูลส่วนกลางก็ต่อเมื่อนักพัฒนาคนนั้นทำการ Push ข้อมูลไปยัง Central Repository เท่านั้น
สำหรับบทความนี้เราจะพูดถึง Git โดยเฉพาะ ซึ่งปัจจุบันได้รับความนิยมใช้กันอย่างกว้างขวาง หากพูดถึง Git หลายคนยังสับสนกับ GitHub ซึ่งทั้งสองอย่างนี้เป็นเรื่องที่เกี่ยวข้องกันแต่ไม่ใช่เรื่องเดียวกัน Git คือ เครื่องมือสำหรับบริหารจัดการ Source Code ที่นักพัฒนาเขียนขึ้นมา ส่วน GitHub เป็นเว็บไซด์สำหรับให้บริการสถานที่ในการจัดเก็บข้อมูลหรือที่เรียกกันว่า Repository สำหรับ Git
Git เกิดขึ้นได้อย่างไร?
Git ถูกพัฒนาขึ้นครั้งแรกในปี 2005 โดย Linus Torvalds ผู้คิดค้นและพัฒนา Linux Kernel เขาใช้เวลาเพียงอาทิตย์เดียวสร้างมันขึ้นมาเพื่อใช้ จัดการกับ Source Code ของ Linux Kernel ซึ่งขณะนั้นมีผู้เข้าร่วมพัฒนาเป็นจำนวนมาก (Linux Kernel ใช้ BitKeeper ในการควบคุม Source Code ก่อนการเกิดของ Git) การเกิดขึ้นของ Git นั้นเรียกได้ว่าเป็นการปฏิวัติวงการพัฒนาซอฟต์แวร์ให้ก้าวกระโดดไปอีกขั้นที่ใหญ่มาก
GitHub ก่อตั้งขึ้นในปี 2007 จากนั้นตามมาด้วย Bitbucket ในปี 2010 และ GitLab ในปี 2011 ทั้งหมดนี้มีพื้นฐานมาจากสิ่งที่ Torvalds ใช้เวลาหนึ่งอาทิตย์สร้างขึ้นมา Source Code จำนวนมากถูกกระจายไปสู่นักพัฒนาเป็นวงกว้างผ่าน Central Repository เหล่านี้ เพื่อให้เหล่านักพัฒนานำไปพัฒนาต่อยอดให้เกิดประโยชน์ในสายงานด้านต่าง ๆ ทุกวันนี้ Source Code แทบทุกอย่างล้วนแต่สามารถหาได้จาก GitHub แทบทั้งสิ้น นับตั้งแต่ Startup ไปจนถึงบริษัท Tech ระดับทอปเช่น Google, Microsoft ต่างใช้มันเป็นตัวหลักในการบริหารจัดการ Source Code ของตน จากการสำรวจในปี 2018 พบกว่านักพัฒนา 88.4% ใช้ Git ในการบริหารจัดการ Source Code
Git ใช้อย่างไร?
การใช้งาน Git นั้นมีอยู่สองวิธีหลัก คือ ใช้งานผ่านคำสั่ง Command line สองคือใช้งานผ่าน GUI Clients ต่าง ๆ เช่น GitHub Desktop, SourceTree TortoiseGit เป็นต้น
ใช้ Git อย่างไรให้เกิดประโยชน์?
Commit Early, Commit Often
ถามว่าแล้วเราต้อง Commit บ่อยแค่ไหน? คำตอบคือบ่อยเท่าที่จะบ่อยได้ ในชีวิตการทำงานจริง ๆ หลายครั้งที่เราต้องทำงานกับ Feature ที่ใหญ่และซับซ้อน การ Commit ไม่จำเป็นต้องรอให้ทุกอย่างเสร็จเรียบร้อย แต่ควรเกิดขึ้นบ่อยที่สุดเท่าที่เรามีการแก้ไขปรับเปลี่ยน หรือเขียน Code เพิ่มขึ้นมา หากเปรียบเทียบให้เห็นภาพง่ายที่สุดก็คงจะเหมือนกับการที่เราพิมพ์งานแล้วต้องไม่ลืมกด Save
Write meaningful commit messages
Commit message ก็สำคัญไม่แพ้กันกับการ Commit บ่อย ๆ ดังนั้นคำที่ใช้ย่อมต้องมีความหมายอ่านแล้วเข้าใจว่าเราทำอะไรไปในการ commit ครั้งนี้
สิ่งที่เปลี่ยนไป บอกเราได้ว่ามันมีการเปลี่ยนแปลง แต่สิ่งที่จะอธิบายให้เรารู้ว่าเหตุใดจึงมีการเปลี่ยนแปลง คือ commit message ที่เราเขียน
การเขียน Commit message ที่ดีเป็นการบันทึกเรื่องราวทีเกิดขึ้น ณ ขณะนั้น เพื่อที่เพื่อนร่วมงานหรือแม้กระทั่งตัวเราเองที่อาจต้องกลับมาอ่านในอนาคต เข้าใจว่า ณ ขณะนั้นเราคิดอะไร เราติดปัญหาอะไร และเราแก้ไขยังไง
Branching policy
ขึ้นชื่อว่าการพัฒนา ย่อมต้องมีการลองผิดลองถูกบ้างในบางครั้ง ที่สำคัญคือการลองผิดลองถูกเหล่านั้นต้องไม่ส่งผลกระทบกับงานหลักหรือเพื่อนที่ทำงานร่วมกับเรา Branch คือทางออกที่ช่วยจัดการปัญหาเหล่านั้น การเพิ่มหรือลบ branch บน Git นั้นเป็นเรื่องง่ายที่หลายคนทำอยู่เสมอ แต่หากใช้งานอย่างพร่ำพรื่อโดยขาดการบริหารจัดการที่ดีย่อมไม่เป็นผลดีต่อตัว Project และผู้ที่ทำงานร่วมกัน สำหรับแนวทางในการบริหาร Branch นั้นไม่มีแนวทางที่ตายตัว หากไม่รู้จะเริ่มยังไงผมแนะนำให้ทำความเข้าใจเรื่อง A successful Git branching model ก่อนถึงจะมองเห็นภาพที่ชัดเจน
Pull requests
เมื่อเราพัฒนา Feature ใด ๆ เสร็จเราต้องมีการประกาศให้ผู้ร่วมงานรู้ว่าเราทำเสร็จแล้วนะและ Pull Requests คือพื้นที่ที่เราจะใช้บอกเพื่อนร่วมงานทุกคน เมื่อเขารู้ก็จะเข้ามา Review ว่ามีอะไรเปลี่ยนไปบ้าง ซึ่งแน่นอนว่าต้องมี Comment ต่าง ๆ การสร้าง Pull Requests ก็เป็นเรื่องไม่ยากนัก Check out Github’s guide.
Code reviews
ทำไมต้องทำ Code Review? ทำแล้วมีประโยชน์อะไรบ้าง?
บางครั้งคนเรามักจะมองไม่เห็นความผิดพลาดของตนเอง แต่บ่อยครั้งที่เรามักจะมองเห็นความผิดพลาดของคนอื่น
นี่คือเหตุผลที่เราต้องมี Code Review เพื่อที่จะให้คนอื่นมาช่วยหา Bug ที่เราอาจมองข้ามไปตลอดจนถึงการเปิดพื้นที่ให้มีการพูดคุยติชมเพื่อพัฒนาให้ Code ที่เขียนมีประสิทธิภาพขึ้น อ่านง่ายขึ้น สิ่งแรกที่จะต้องทำก่อนเปิดให้ Review Code คือผู้เขียนต้องทำการ Review สิ่งที่ตัวเองเขียนว่าเพื่อให้มั่นใจว่าไม่ได้เขียนอะไรที่อาจทำให้ผู้ที่มา Review ต้องเสียเวลาในการทำความเข้าใจ
แหล่งอ้างอิง