Cách quản lý cấu hình Git hiệu quả

1. Xây dựng một chiến lược branch thống nhất

   • Khi các thành viên trong nhóm cùng làm việc nhưng có kiến thức chuyên môn đa dạng, cách tiếp cận workflow có thể xung đột nhau
   • Để ngăn điều này, người lãnh đạo cần thiết lập một chiến lược branch duy nhất và phổ biến cho mọi người
   • Việc quyết định branch workflow có thể khác nhau tùy theo nhiều yếu tố như quy mô nhóm, mức độ kinh nghiệm, nhu cầu mở rộng và các ràng buộc công việc
   • Nhóm phát triển có thể đi theo workflow đã được xác định sẵn hoặc tự xây dựng workflow phù hợp với nhu cầu của nhóm
   • Nội dung workflow có thể bao gồm
     • Workflow tập trung: có một repository và một branch master. Có rủi ro ghi đè thay đổi
     • Feature branch: mỗi khi thêm tính năng mới thì tạo một branch mới. Các commit liên quan đến tính năng sẽ nằm trong feature branch đó
     • Git Flow: là một dạng cực đoan của feature branch. Khi phát triển với Git Flow sẽ có branch phát triển tách biệt với branch master. Hỗ trợ branch tính năng, branch phát hành và branch hotfix. Việc phát triển diễn ra trên branch phát triển, sau đó chuyển sang branch phát hành rồi merge vào branch master
     • Phát triển theo task-branch: GitLab Flow là một ví dụ của kiểu phát triển này. Đây là hình thức phát triển lấy tính năng làm trung tâm, kết hợp feature branch với theo dõi issue. GitLab Flow dùng các branch chuyên biệt riêng để duy trì nhiều môi trường như staging, kiểm thử vận hành và production. Điều này giúp bảo đảm các thay đổi được commit đều được kiểm thử trên mọi môi trường
   • Tác động đến cộng tác:
     • Khi mọi người phối hợp trên cùng một workflow, nguy cơ ghi đè code hoặc làm hỏng branch master sẽ giảm đi
     • Tất cả thành viên đều quen với quy trình phát triển và triển khai nên có thể dễ dàng đóng góp vào công việc của nhau
     • Một chiến lược branch rõ ràng và ngắn gọn sẽ tạo ra vòng tuần hoàn tích cực cho việc merge code mới và phát triển dự án
     • Môi trường như vậy giúp các thành viên lên lịch họp cũng như quản lý deadline và khối lượng công việc
     • Ảnh hưởng của từng workflow đến cộng tác
       • Workflow tập trung: hiệu quả với nhóm nhỏ (dưới 5 lập trình viên), nơi hai nhà phát triển có thể giao tiếp tốt để tránh cùng lúc làm trùng lặp trên cùng một đoạn code
       • Feature branch và GitFlow: cần nhiều code review hơn, quy tắc push, người phê duyệt code và kiểm thử ở phạm vi rộng hơn nên gắn kết được nhiều nhóm khác nhau
       • Phát triển theo task-branch: giúp các thành viên chia nhỏ yêu cầu thành những khối tính năng nhỏ được chuyển thành task branch. Workflow này bao gồm các thực hành cộng tác như code snippet, code review và unit test. Khi kiểm thử thất bại, các thành viên sẽ cùng phối hợp để xác định điều gì đã xảy ra

2. Commit thường xuyên với đơn vị nhỏ

   • Nếu quá ưu tiên mức độ hoàn thiện, bạn có thể chỉ tạo các commit lớn khi dự án gần hoàn tất
   • Nếu bỏ qua việc xác minh tính năng đơn giản và các bước nhỏ, bạn có thể phát triển sai chức năng hoặc tốn thời gian theo một hướng không đúng
   • Hãy commit mỗi khi có code và bài kiểm thử đang hoạt động
   • Cần đơn giản hóa dự án thành các bước nhỏ và tìm cách đạt mục tiêu lớn thông qua các commit thường xuyên
   • Tác động đến cộng tác:
     • Khi hình thành văn hóa commit thường xuyên, mọi người sẽ có khả năng quan sát kho mã nguồn tốt hơn và dễ biết các thành viên khác đang làm gì
     • Chia sẻ công việc thông qua feature branch hoặc merge request có thể ngăn việc các thành viên khác làm trùng lặp
     • Ngay cả khi chưa sẵn sàng để review, bạn vẫn nên push thường xuyên lên feature branch
     • Chia sẻ công việc trước khi hoàn thành sẽ thúc đẩy thảo luận và phản hồi, từ đó cải thiện chất lượng ngay cả trước code review
     • Việc chia công việc thành nhiều commit sẽ trở thành thông tin hữu ích cho lập trình viên và các nhóm khác khi xem xét code về sau
     • Có thể xác định rõ tính năng đã được phát triển như thế nào theo từng commit
     • Có thể giữ nguyên lịch sử thay đổi không liên quan, rollback về thời điểm mong muốn hoặc chỉ hoàn tác có chọn lọc những thay đổi mã cụ thể

3. Viết commit message chi tiết

   • Commit message không chỉ nên phản ánh nội dung của commit mà còn phải thể hiện ý đồ của lập trình viên
   • Commit message cần giải thích lý do vì sao thay đổi đó xảy ra
   • Ví dụ về commit message tốt: “Kết hợp template để giảm mã trùng lặp trên giao diện người dùng”
   • Những từ như ‘thay đổi’, ‘cải thiện’, ‘sửa’, ‘tái cấu trúc’ trong commit message không phải là thông tin hữu ích
   • Tác động đến cộng tác:
     • Commit message chi tiết giúp tăng tính minh bạch và cung cấp khả năng quan sát tiến độ, từ đó giúp đồng đội, khách hàng và những người đóng góp trong tương lai hiểu được quy trình phát triển
     • Khi thực hiện code review, commit message giúp bám theo quy trình lặp lại và xác nhận những thay đổi xuất hiện sau phát hành, trao đổi hoặc thay đổi yêu cầu
     • Commit message chi tiết giúp nhóm QA và bảo mật xác định khu vực có vấn đề khi kiểm tra code, đồng thời hỗ trợ hoàn tác những thay đổi cụ thể
     • Viết commit message kỹ lưỡng giúp tránh trùng lặp công việc giữa các thành viên khác, giảm thiểu chậm trễ và giữ tiến độ dự án ổn định

4. Phát triển bằng branch

   • Phát triển trên branch cũng giống như sao chép trạng thái hiện tại tại một thời điểm cụ thể rồi làm việc trên đó
   • Dùng branch cho phép thay đổi code mà không ảnh hưởng đến codebase chính
   • Lịch sử thay đổi được quản lý bên trong branch
   • Khi code đã sẵn sàng, có thể merge vào branch master
   • Việc coding trên branch giúp tiếp cận phát triển một cách có hệ thống hơn
   • Có thể tách riêng bản nháp đang phát triển khỏi mã master ổn định đã qua kiểm thử, và quản lý chúng độc lập
   • Tác động đến cộng tác:
     • Cho phép các thành viên thử nghiệm giải pháp sáng tạo và đổi mới để giải quyết các vấn đề phức tạp
     • Nhóm phát triển có thể thoải mái thử thách ý tưởng sáng tạo mà không còn lo làm ảnh hưởng đến branch master
     • Có thể cùng phối hợp để xác minh giải pháp hoạt động bình thường trước khi merge vào branch master
     • Nhóm vận hành, QA và bảo mật có thể review code trước khi phát hành, đồng thời bảo đảm mọi thành viên đều có cơ hội đưa ra ý tưởng và thảo luận các vấn đề tiềm ẩn trước khi release

5. Thực hiện code review định kỳ

   • Bảo đảm cải tiến liên tục và ngăn chặn code không ổn định
   • Khi có code cần review, nên yêu cầu một đồng nghiệp, thành viên nhóm hoặc chuyên gia lĩnh vực hiểu rõ dự án thực hiện code review
   • Những điểm cần lưu ý khi thực hiện code review:
     • Giải thích những thay đổi nào là cần thiết
     • Đưa ra phương án thay thế nhưng nên giả định rằng lập trình viên đã cân nhắc điều đó rồi
     • Ngay cả trong quá trình giải quyết vấn đề cũng nên tìm cách đơn giản hóa code
   • Tác động đến cộng tác:
     • Code review mang lại những góc nhìn khác nhau về việc giải quyết vấn đề và cách triển khai
     • Là thêm một cặp mắt để tìm ra bug, vấn đề logic hoặc các corner case tiềm ẩn
     • Giúp giảm nhẹ các vấn đề có thể phát sinh khi vượt qua những issue khó và tiến tới phát hành
     • Có thể review giải pháp cho vấn đề, đưa ra ý kiến và cộng tác cùng đồng đội
     • Có thể học được nhiều cách coding, kinh nghiệm workflow và phương pháp giải quyết vấn đề mới