Hướng tới quy trình làm việc Git tốt hơn

Mình đã tổng hợp các cách để sử dụng Git hiệu quả hơn.

0. Cấu trúc repo
   • Git là hệ thống quản lý phiên bản phân tán nên có thể được tổ chức theo nhiều cách như tập trung, kiểu GitHub/GitLab, hoặc phân tầng
1. Cấu trúc nhánh
   • GitHub Flow: đặt Main, sau đó tạo nhánh tính năng hoặc nhánh sửa lỗi, nhận phản hồi rồi hợp nhất
   • Git Flow: phù hợp hơn với phát triển truyền thống thay vì phát hành thường xuyên
     • Tạo nhánh Feature rồi hợp nhất vào nhánh Develop
     • Khi nhánh Develop đã đủ ổn định thì tạo nhánh Release(Stage), chỉ sửa lỗi trên đó rồi sau này hợp nhất vào Develop và Master
     • Khi sẵn sàng phát hành thì hợp nhất vào nhánh Master, sau đó chỉ còn hotfix
   • GitLab Flow: dạng trung gian giữa Git Flow phức tạp và GitHub Flow quá đơn giản
     • Thay vì nhánh Release chỉ tồn tại tạm thời như trong Git Flow, dùng nhánh Stage được duy trì liên tục
     • Hotfix được áp dụng vào Production và Stage, còn sửa lỗi được phản ánh vào Stage và Develop
   • Perforce Stream: có lợi khi phải quản lý nhiều bản phát hành
     • Khi sửa lỗi ở Release thì lan truyền về Main-Develop
     • Khi phát triển tính năng ở Develop thì giải quyết xung đột rồi phản ánh vào Main
   • Trunk-based: nỗ lực sử dụng Main(Master) hiệu quả hơn, chủ yếu được các công ty công nghệ lớn dùng
     • Duy trì Main lâu dài và không sửa lỗi riêng trên nhánh phát hành
     • Tính năng được hợp nhất ở trạng thái Off bằng feature flag để luôn giữ mã nguồn mới nhất
2. Commit
   • Convention: thường dùng Angular convention, nhưng cũng có thể dùng emoji nếu đã thống nhất trong nhóm
   • Đơn vị: nên commit theo đơn vị nhỏ nhất, nhưng nhóm vẫn cần thống nhất thế nào là đơn vị nhỏ nhất
     • Có thể chia nhỏ thay đổi theo hunk để staging
     • Nếu có thể so sánh thay đổi theo đơn vị delta thì sẽ thuận tiện
   • Commit mang tính thăm dò và lịch sử tuyến tính: cách commit thường xuyên để giữ context nhưng vẫn duy trì lịch sử commit tuyến tính
     • Lưu mỗi khi cần lưu công việc, như khi dùng stash hoặc thử nghiệm prototype
     • Checkout đến nơi cần checkout, tiếp tục commit rồi dùng rebase để giữ lịch sử tuyến tính
     • Sẽ tiện hơn nếu dùng công cụ git-branchless
     • git sl: theo dõi các nhánh ẩn danh và trực quan hóa lịch sử commit tốt
     • git prev và git next: giúp checkout theo đơn vị trước/sau dễ dàng
     • git sync: rebase lên Main
     • git move: có thể chuyển commit đến vị trí mong muốn
     • git restack: khôi phục khi thứ tự lịch sử commit bị vỡ do rebase hoặc commit --amend
     • git undo: có thể hoàn tác
3. Hợp nhất
   • Patch Stack: cách chia nhỏ để review như tính năng[1/3], tính năng[2/3], tính năng[3/3]
   • Xung đột hạng nhất: Jujutsu, tương thích với Git, ghi lại xung đột vào commit nên ít khi phải giải quyết lại cùng một xung đột về sau
   • 3 Way Diff: trong trường hợp của Jujutsu, khi xảy ra xung đột thì Base-Ours được hiển thị dưới dạng diff, còn Theirs dưới dạng snapshot nên trực quan. Tuy nhiên vẫn có nhu cầu xem tô sáng cú pháp trong IDE/editor hoặc xem diff Base-Their
   • Xung đột nhị phân: Git để người dùng tự xử lý khi file nhị phân bị xung đột, nhưng cá nhân tác giả đã tạo một công cụ đơn giản để sinh file Base và Their
   • Patch và mail: giới thiệu về cách hợp nhất mang tính truyền thống hơn(?)
     • git request-pull là lệnh tạo pull request
     • Có thể gửi patch qua mail bằng git send-mail, rồi áp dụng patch bằng git am
4. Các cách quản lý khác
   • Worktree: Git history vẫn được chia sẻ, nhưng có thể checkout file làm việc ra nhiều nơi như nhánh trong SVN để tiến hành nhiều công việc cùng lúc
   • Git LFS: cách quản lý file dung lượng lớn
   • Partial clone và partial checkout: clone một phần để giảm thời gian tải xuống, và checkout một phần để chỉ làm việc với thư mục mong muốn
   • Scalar: giúp quản lý các repository khổng lồ dễ dàng hơn nhờ nỗ lực của Microsoft