สู่เวิร์กโฟลว์ Git ที่ดีกว่า
(black7375.tistory.com)ได้รวบรวมวิธีใช้งาน Git ให้มีประสิทธิภาพมากขึ้น
- โครงสร้างรีโพซิทอรี
- Git เป็นระบบควบคุมเวอร์ชันแบบกระจาย จึงสามารถจัดโครงสร้างได้หลากหลาย เช่น แบบศูนย์กลาง, แบบ GitHub/GitLab, หรือแบบลำดับชั้น
- โครงสร้างบรานช์
- GitHub Flow: มี Main แล้วสร้างบรานช์สำหรับฟีเจอร์หรือบั๊ก จากนั้นรับฟีดแบ็กก่อนรวมกลับ
- Git Flow: เหมาะกับการพัฒนาแบบดั้งเดิมมากกว่าการดีพลอยบ่อย ๆ
- สร้าง Feature branch แล้วรวมเข้า Develop branch
- เมื่อ Develop branch มีความพร้อมมากพอ จะสร้าง Release(Stage) branch ขึ้นมา จากนั้นแก้เฉพาะบั๊ก แล้วค่อยรวมกลับเข้า Develop และ Master ภายหลัง
- เมื่อพร้อมรีลีสแล้วให้รวมเข้า Master branch และหลังจากนั้นจะมีเพียง hotfix เท่านั้น
- GitLab Flow: รูปแบบกึ่งกลางระหว่าง Git Flow ที่ซับซ้อนกับ GitHub Flow ที่เรียบง่ายเกินไป
- แทนที่จะใช้ Release branch แบบชั่วคราวเหมือนใน Git Flow จะใช้ Stage branch ที่คงอยู่ต่อเนื่อง
- hotfix สะท้อนไปยัง Production และ Stage ส่วนการแก้บั๊กสะท้อนไปยัง Stage และ Develop
- Perforce Stream: เหมาะเมื่อจำเป็นต้องดูแลหลายรีลีส
- หากแก้บั๊กใน Release ก็จะกระจายกลับไปยัง Main-Develop
- หากพัฒนาฟีเจอร์ใน Develop ก็จะเคลียร์คอนฟลิกต์แล้วสะท้อนไปยัง Main
- Trunk-based: ความพยายามใช้งาน Main(Master) ให้มีประสิทธิภาพยิ่งขึ้น ซึ่งบริษัทบิ๊กเทคใช้กันมาก
- คง Main ไว้ระยะยาว และไม่แก้บั๊กแยกต่างหากใน release branch
- ฟีเจอร์จะถูกรวมเข้ามาในสถานะปิดด้วย feature flag เพื่อให้โค้ดเป็นเวอร์ชันล่าสุดอยู่เสมอ
- คอมมิต
- คอนเวนชัน: โดยทั่วไปมักใช้ Angular convention แต่ก็อาจตกลงกันใช้ emoji ได้เช่นกัน
- หน่วย: ควรคอมมิตเป็นหน่วยย่อยที่สุดเท่าที่ทำได้ แต่ก็ยังต้องตกลงกันในทีมว่าหน่วยย่อยขั้นต่ำคืออะไร
- สามารถแยกการเปลี่ยนแปลงเป็น Hunk เพื่อทำ staging แบบละเอียดได้
- หากเทียบความเปลี่ยนแปลงในระดับ Delta ได้ก็จะสะดวก
- speculative commit และประวัติแบบเชิงเส้น: วิธีคอมมิตบ่อย ๆ เพื่อรักษาคอนเท็กซ์ของงานไว้ พร้อมกับคงประวัติคอมมิตให้เป็นเส้นตรง
- เก็บบันทึกทุกครั้งที่ต้องการเก็บงาน เช่น ตอนใช้ Stash หรือทดลองทำ prototype
- checkout ไปยังจุดที่ต้องการทุกแห่ง แล้วคอมมิตต่อไปเรื่อย ๆ ก่อนใช้ rebase เพื่อคงประวัติแบบเชิงเส้น
- จะสะดวกขึ้นหากใช้เครื่องมือชื่อ git-branchless
git sl: ช่วยติดตาม anonymous branch และแสดงภาพประวัติคอมมิตได้ดีgit prevและgit next: ทำให้ checkout ไปยังหน่วยก่อนหน้า/ถัดไปได้ง่ายgit sync: rebase กับ Maingit move: ย้ายคอมมิตไปยังตำแหน่งที่ต้องการได้git restack: กู้ลำดับประวัติคอมมิตเมื่อเสียลำดับจากrebaseหรือcommit --amendเป็นต้นgit undo: ยกเลิกได้
- การรวม
- Patch Stack: วิธีรีวิวโดยแยกงานเป็นส่วนย่อย เช่น ฟีเจอร์[1/3], ฟีเจอร์[2/3], ฟีเจอร์[3/3]
- first-class conflict: Jujutsu ซึ่งเข้ากันได้กับ Git จะบันทึกคอนฟลิกต์ไว้ในคอมมิต ทำให้คอนฟลิกต์ที่เคยแก้แล้วมีโอกาสเกิดซ้ำน้อยลงในภายหลัง
- 3 Way Diff: ในกรณีของ Jujutsu เมื่อเกิดคอนฟลิกต์ จะแสดง Base-Ours เป็น Diff และ Theirs เป็น snapshot ทำให้เข้าใจได้ตรงไปตรงมา แต่บางครั้งก็อาจยังต้องการ syntax highlighting จาก IDE/เอดิเตอร์ หรืออยากดู Base-Their Diff
- binary conflict: เมื่อไฟล์ไบนารีเกิดคอนฟลิกต์ Git มักปล่อยให้จัดการกันเอง แต่โดยส่วนตัวผู้เขียนได้ทำเครื่องมือง่าย ๆ เพื่อสร้างไฟล์ Base และ Their ขึ้นมา
- patch และเมล: แนะนำวิธีรวมแบบดั้งเดิมมากขึ้น
git request-pullเป็นคำสั่งสำหรับสร้าง pull request- สามารถส่ง patch ทางเมลด้วย
git send-mailและใช้git amเพื่อปรับใช้ patch ได้
- วิธีจัดการอื่น ๆ
- Worktree: ใช้ Git history ร่วมกัน แต่ checkout เฉพาะไฟล์งานแยกหลายตำแหน่งได้เหมือน SVN branch จึงทำงานหลายอย่างพร้อมกันได้
- Git LFS: วิธีจัดการไฟล์ขนาดใหญ่
- partial clone และ partial checkout: clone เฉพาะบางส่วนเพื่อลดเวลาดาวน์โหลด และ checkout เฉพาะบางส่วนเพื่อทำงานเฉพาะไดเรกทอรีที่ต้องการ
- Scalar: ช่วยให้จัดการรีโพซิทอรีขนาดใหญ่ได้ง่ายขึ้นจากความพยายามของ Microsoft
ยังไม่มีความคิดเห็น