พอดีนั่งทำ project อยู่แล้วรู้สึกว่าตอน commit git อยากมี standard สักอย่างในการ commit ซึ่งก็พอลองไปหาดูใน Google ก็เหมือนกับมีหลากหลายแบบมาก เลยมาถามความเห็นว่าแต่ละคนมีแนวทางในการ commit git โดยใช้ format อะไรเป็น standard กันครับ
แตก branch แล้วทำแต่ละ features ให้เสร็จและก็ merge เข้า production มั่ง
ผมเพิ่งย้ายมาใช้ https://www.conventionalcommits.org/en/v1.0.0-beta.4/ อันนี้ ผมว่าก็โอเคนะครับ อ่านง่าย
“fixed fn aaa”
ของผมไม่สนใจ commit description เพราะถือเป็น work in progress แต่จะไปเน้นที่ Pull Request (PR) แทน โดยมีรายละเอียดประมาณนี้
+1 น่าสนใจ
ผมว่า commit msg มีประโยชน์กับ reviewer อยู่ดีนะ
ใช่ครับ แต่มีประโยชน์แค่ใน Pull Request นั้นๆ พอ Merge เข้าไปใน Master branch แล้ว สำหรับผมมันไม่มีประโยชน์แล้ว เพราะหลายๆครั้งจะเป็น Refactor xx, fix comment yyy
แต่ส่วนมากระบบมันก็ดึง commit message มาใส่ PR ไม่ใช่เหรอครับ?
ขึ้นอยู่กับว่าเราตั้งให้ Merge PR เข้า Master branch แบบไหนครับ
อันนี้ตัวอย่างของ Github https://help.github.com/en/articles/about-merge-methods-on-github
อันนี้ของตัวอย่าง Azure DevOps https://devblogs.microsoft.com/devops/pull-requests-with-rebase/
หมายถึงว่ามันจะดึง commit message มารอเอาไว้ก่อนที่จะกด create PR น่ะครับ แล้วเราก็สามารถจะ edit หรือใช้ commit message นั้นๆ ไปเลยก็ได้
แต่คิดไปคิดมา แบบที่คุณทำอ่ะเป็น practice ที่แม่นสุดแล้วครับ
ขึ้นอยู่กับ VCS hosting แต่ละเจ้าครับ ถ้า Bitbucket จะดึง commit msg มาเป็นค่า default ของ PR description แต่ถ้า Github จะไม่มีครับ ยกเว้นกำหนด .github/pull_request_template.md ไว้ใน root directory ก็จะใช้ template นั้นแทน
.github/pull_request_template.md
เรียกว่า squash merge นี่เอง ปกติ ใช้ Merge pull request แล้วคอมเม้นต์คนอื่นทำมาหมดเลย ทำให้ตัว master ปนเปื้อนจริงๆ
มือใหม่!! ใหม่จริงๆนะ
แตก branch แล้วทำแต่ละ features ให้เสร็จและก็ merge เข้า production มั่ง
ผมเพิ่งย้ายมาใช้ https://www.conventionalcommits.org/en/v1.0.0-beta.4/ อันนี้ ผมว่าก็โอเคนะครับ อ่านง่าย
“fixed fn aaa”
ของผมไม่สนใจ commit description เพราะถือเป็น work in progress แต่จะไปเน้นที่ Pull Request (PR) แทน โดยมีรายละเอียดประมาณนี้
+1 น่าสนใจ
ผมว่า commit msg มีประโยชน์กับ reviewer อยู่ดีนะ
ใช่ครับ แต่มีประโยชน์แค่ใน Pull Request นั้นๆ พอ Merge เข้าไปใน Master branch แล้ว สำหรับผมมันไม่มีประโยชน์แล้ว เพราะหลายๆครั้งจะเป็น Refactor xx, fix comment yyy
แต่ส่วนมากระบบมันก็ดึง commit message มาใส่ PR ไม่ใช่เหรอครับ?
ขึ้นอยู่กับว่าเราตั้งให้ Merge PR เข้า Master branch แบบไหนครับ
อันนี้ตัวอย่างของ Github https://help.github.com/en/articles/about-merge-methods-on-github
อันนี้ของตัวอย่าง Azure DevOps https://devblogs.microsoft.com/devops/pull-requests-with-rebase/
หมายถึงว่ามันจะดึง commit message มารอเอาไว้ก่อนที่จะกด create PR น่ะครับ แล้วเราก็สามารถจะ edit หรือใช้ commit message นั้นๆ ไปเลยก็ได้
แต่คิดไปคิดมา แบบที่คุณทำอ่ะเป็น practice ที่แม่นสุดแล้วครับ
ขึ้นอยู่กับ VCS hosting แต่ละเจ้าครับ ถ้า Bitbucket จะดึง commit msg มาเป็นค่า default ของ PR description แต่ถ้า Github จะไม่มีครับ ยกเว้นกำหนด
.github/pull_request_template.md
ไว้ใน root directory ก็จะใช้ template นั้นแทนเรียกว่า squash merge นี่เอง ปกติ ใช้ Merge pull request แล้วคอมเม้นต์คนอื่นทำมาหมดเลย ทำให้ตัว master ปนเปื้อนจริงๆ
มือใหม่!! ใหม่จริงๆนะ