แนวทางการใช้ Git ที่ดี 7 ข้อ

เดี๋ยวนี้ Git เป็น versioning system ที่ได้รับความนิยมเป็นอย่างสูง และเชื่อว่า developer ส่วนใหญ่ก็น่าจะรู้จัก การใช้ Git กันหมด แต่นอกจากเราจะรู้จักมันแล้ว เราควรใช้มันได้เป็นอย่างดีด้วย บทความนี้จึงนำเสนอคำแนะนำโดยทั่วไปเกี่ยวกับ แนวทางการใช้ Git ที่ดี

โดยทั่วไปเรามักใช้ Git ร่วมกันเป็นทีม แปลว่าคนในทีมควรใช้ Git ไปในทางเดียวกันซึ่งปกติแล้วแต่ละทีมก็จะมีแนวทางการใช้ Git เป็นของตัวเอง แต่อย่างน้อย ผมเชื่อว่า 7 ข้อต่อไปนี้ น่าจะเป็นแนวทาง การใช้ Git ที่หลายทีมใช้คล้ายๆ กัน

1. อย่าสั่ง git push ไปที่ master ตรงๆ ให้สร้าง branch ขึ้นมาใหม่เมื่อต้องแก้ไขโค้ด

โดยทั่วไปแล้ว เมื่อเราต้องการแก้โค้ด เราจะสร้าง branch ขึ้นมาก่อน โดยใช้คำสั่ง git branch -b <branch_name> หรือหากต้องการดู branch อื่นๆ ใน repository ก็ใช้คำสั่ง git branch -a และเราสามารถไปดูโค้ดของแต่ละ branch ด้วยคำสั่ง git checkout <branch_name>

ทริคหนึ่งก็คือเราสามารถใช้ git checkout - เพื่อย้อนกลับไป branch ก่อนหน้าได้เลยโดยไม่ต้องระบุชื่อ branch 

อย่างไรก็ตาม โดยทั่วไปแล้ว repository owner จะกำหนด permission ให้เราไม่สามารถ push ไปที่ master ได้ตรงๆ อยู่แล้วล่ะ

2. กำหนดข้อมูลโปรไฟล์ของเราให้ชัดเจนอยู่เสมอ

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

นอกจากทำให้รู้ว่าใครเป็นคนสร้าง commit นี้ขึ้นมาแล้ว เรายังสามารถใช้คำสั่ง git blame <file_name> เพื่อดูเป็นรายบรรทัดเลยว่า ใครเขียนโค้ดบรรทัดไหน เมื่อไหร่ ในไฟล์นั้นๆ ได้เลย

แม้ชื่อคำสั่งจะเป็นคำว่า blame ก็ไม่ได้หมายความว่าเป้าหมายของคำสั่งนี้เอาไว้ให้เราไปต่อว่า developer คนอื่น เพราะนั่นไม่ได้ช่วยแก้ปัญหาอะไรเลย ออกจะแย่ลงด้วยซ้ำ (เวลาทำงานเราต้องห้ามเบลมกันเองนะ) แต่มันช่วยให้เราสามารถถามได้ถูกคนว่า logic ตรงบรรทัดนั้นมาได้ยังไง ทำไมถึงเขียนโค้ดแบบนั้นมา มีแนวคิดยังไง ซึ่งจะช่วยให้เราเข้าใจโค้ดได้มากขึ้น และแก้ไขโค้ดได้ง่ายขึ้น

วิธีการตั้งค่า ชื่อ และอีเมล ของเรา สามารถตั้งได้โดยใช้คำสั่ง

git config --global user.name "<Your-Full-Name>"
git config --global user.email "<your-email-address>"
git config --list

3. เขียน commit message ให้มีความหมายชัดเจนอยู่เสมอ

ต้องปรับ mindset ก่อนว่า commit message คือ communication tools อย่างหนึ่ง ดังนั้นเวลาเขียน commit message ให้ตั้งใจเขียนให้ดี มันจะเป็นประโยชน์ทั้งต่อตัวเราเอง และทีมในอนาคต

เราสามารถดู commit history ได้ด้วยคำสั่ง git log ซึ่งผลที่ได้มันควรจะเล่าเรื่องราวการเปลี่ยนแปลงต่างๆ ของ repository ของเราได้ชัดเจนว่ามีอะไรเกิดขึ้นบ้าง ถ้าหากมีใครสักคนเขียนมาแค่ว่า “Bugifx” หรือ “Refactoring auth” ซึ่งแทบไม่บอกรายละเอียดอะไรเลย ก็คงจะไม่มีประโยชน์อะไรเท่าไหร่นัก

แนวทางทั่วไปก็คือ เขียนบรรทัดแรกเป็นสรุปรวมๆ ของ commit นั้นๆ จากนั้น ก็เหมือนเขียนบทความสั้นๆ ทั่วไป ก็คืออธิบายเรื่องราวต่างๆ ที่เกิดขึ้น

มีคนเขียนแนวทางการเขียน git message ที่คิดว่าน่าสนใจเลยทีเดียว ไว้ที่นี่

นี่คือ commit message จาก Bitcoin Core ซึ่งนับเป็นตัวอย่างที่ดีอันหนึ่งในการเขียน commit message

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always 
  called with bits = failbit, all it did was immediately raise an
  exception. Get rid of those variables, and replace the setstate
  with direct exception throwing (which also removes some dead 
  code).

   As a result, good() is never reached after a failure (there are 
  only 2 calls, one of which is in tests), and can just be replaced 
  by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete 
  them.

4. commit เฉพาะไฟล์ที่เกี่ยวข้องกับ commit เท่านั้น

เราควรเลือก commit ไฟล์เฉพาะที่เกี่ยวข้องกับ commit นั้นจริงๆ เท่านั้น แปลว่า ถ้าเราแก้ไขไป 3 ไฟล์ แต่มีแค่ 2 ไฟล์เท่านั้นที่เกี่ยวข้อง เราก็ใช้ git add กับแค่ 2 ไฟล์ที่เกี่ยวข้องเท่านั้น ไม่ควรใช้ git add . จากนั้นก็รัน git commit เพื่อ commit  แค่  2 ไฟล์นั้น ไม่อย่างนั้นอาจทำคนอื่นในทีมสับสนได้ ว่าไฟล์ที่ส่งเข้ามาใน repository นั้นเกี่ยวกับ commit ตรงไหน ซึ่งให้คนอื่นต้องเสียเวลาโดยไม่จำเป็น

5. หลีกเลี่ยงการ rewrite ประวัติของ master 

Git ช่วยให้เราบันทึกประวัติของ repository ได้ต่อมาเป็นสายยาวเรื่อยๆ แต่ในอีกทางหนึ่ง Git ก็เปิดโอกาสให้เราย้อนกลับไปแก้ประวัติที่ผ่านมาแล้วได้เช่นกัน ซึ่งเราสามารถทำได้หลายวิธี แต่วิธีหนึ่งที่ผมใช้บ่อยๆ ก็คือใช้ git rebase -i

คำสั่งนี้ทำให้เราสามารถย้อนกลับไปแก้ไข commit message ได้, รวม commit ไว้ด้วยกันได้ หรือแม้แต่ลบ commit ที่ผ่านมาแล้วทิ้งไปก็ได้

เราควรตัดแต่ง commit ที่เราทำมาให้สวยงามและ make sense ในแต่ละ commit ก่อนที่จะ submit code ไปให้คนอื่นรีวิว ถ้ามองอีกแบบก็คือ ถ้าเราทำตามข้อ 3, 4 อย่างเคร่งครัดแต่แรกแล้ว เราจะพบว่า list of commit นั้นก็คือ task list ดีๆ นี่เอง มันจะบอกว่าเราทำอะไรบ้าง เล่าเรื่องราวว่าโค้ดที่ได้มานั้นเกิดจากการทำอะไรไปบ้างได้เป็นอย่างดี

เมื่อเราต้องการแก้ประวัติบน upstream เราจำเป็นต้องรัน git push --force

จริงๆ แล้ว ไม่เพียงแต่ master branch เท่านั้น แต่เรายังไม่ควร force push ไปยัง branch ใดๆ ก็ตามที่เราใช้ร่วมกับคนอื่นทั้งนั้น ไม่อย่างนั้นอาจทำให้คนอื่นเกิดปัญหาได้จากการเกิด conflict ขึ้นจำนวนมาก และต้องเสียเวลาแก้กันอีกนาน

6. Rebase working branch บ่อยๆ

การเขียนโค้ดโดยอิงจาก code เวอร์ชั่นที่เก่ามากๆ ไปแล้วไม่ค่อยมีประโยชน์ เช่น บางทีเราอาจไป fix bug ที่คนอื่น fix แล้วก็ได้โดยไม่รู้ตัว ดังนั้นเราควร rebase working branch บ่อยๆ เพื่อลด bug และลดการทำงานซ้ำซ้อนกับคนอื่นโดยไม่ตั้งใจ ที่สำคัญคือ ลด conflict กับ upstream branch ด้วย เราสามารถ rebase โดยใช้คำสั่ง

git rebase <upstream_branch>

7. รู้จักใช้เครื่องมืออื่นๆ ของ git ให้เป็น อย่ากลัวคำสั่งที่ไม่เคยใช้

developer มือใหม่หลายคนมักจะใช้ git แค่คำสั่งพื้นฐานอย่าง add / commit / fetch / push เท่านั้น แต่จริงๆ แล้วยังมีคำสั่งอื่นๆ ที่น่าใช้อีกมากมาย เช่น

git cherry-pick
git diff
git stash
git rebase
git restore
git reset
git merge

เราควรฝึกใช้ให้คล่อง จะช่วยให้จัดการ repository และ commit ของเราได้ดียิ่งขึ้น

ที่มา: medium