Quy trình quản lý source code hiệu quả với Git

Tiếp theo bài viết về Git cơ bản hôm nay tác giả tiếp tục muốn chia sẻ cùng các bạn chủ đề tiếp theo liên quan đến việc sử dụng Git trong các dự án: Git flow hay work flow.

Git là một trong những cung cụ quản lý source code rất hiệu quả và dễ sử dụng. Nếu bạn cần dựng Git cho một dự án nhỏ vài người dùng, dự án chạy trong vài tháng,… chắc không có nhiều vấn đề cần chú ý, bạn chỉ cần tạo một repository, rồi mọi người vào cùng nhau làm cho đến khi dự án kết thúc.

Nhưng nếu bạn phải chịu trách nhiệm để dựng quy trình làm việc cho một dự án lớn, vài chục người cùng làm việc, release nhiều lần, cần lưu lại các cột mốc rõ ràng thì đó là chuyện khác. Chúng ta phải có một quy trình đủ tốt để team làm việc hiệu quả nhất có thể được.

Trong bài này tác giả giới thiệu đếu các bạn cách tổ chức quy trình quản lý source code với Git mà tác giả đã tham gia làm việc qua rất nhiều dự án, thành viên của dự án từ 50 đến 100+ người. Quy trình này không chỉ áp dụng được cho Git, bạn có thể thay đổi để áp dụng cho các trình quản lý source code khác như svn…

Các Nhánh

Quy trình quản lý source code tốt hay không nó phụ thuộc vào cách chúng ta tổ chức các nhánh để làm việc như thế nào.

Nhánh Master

Master hay <ABC> tùy dự án bạn đặt tên: đây là nhánh chính lưu toàn bộ source code của dự án, là nhánh code sạch nhất của sản phẩm. Sau một giai đoạn phát triển, bạn sẽ release sản phẩm của mình đến người dùng, code khi release một version mới sẽ được merge về nhánh chính này và sẽ đánh dấu nó để sau này dễ tìm kiếm.

Các nhánh hot fixes

Sau khi bạn kết thúc giai đoạn test sản phẩm mà không phát hiện thấy lỗi nào nghiêm trọng, bạn sẽ tiến hành release nó. Nhưng mọi thứ luôn hoạt động theo cách không như bạn mong muốn, sau khi release xong khách hàng báo chức năng <XYZ> hoạt động không đúng, cần thay đổi gấp. Fix bug giai đoạn này gọi là hot fix. Một sản phẩm có thể có rất nhiều nhánh hot fixes.

Các nhánh Release

Sau những ngày làm việc mệt nhọc của cả team thì đã đến lúc release sản phẩm. Code để chuẩn bị release một version mới sẽ được tách ra từ nhánh phát triển chính (thường có tên: dev) và đưa vào một nhánh riêng để thực hiện các công việc khác như: test, build… quá trình phát triển vẫn tiếp tục ở nhánh dev hay các nhánh features khác.

Nhánh Dev

Mỗi dự án chỉ cần một nhánh dev, nhánh này được dùng xuyên suốt thời gian tồn tại dự án, toàn bộ thành viên sẽ tham chiếu vào nhánh này cho code mới nhất. Khi phát triển một chức năng mới, thành viên dự án sẽ lấy code mới nhất từ đây để tiếp tục công việc.

Các nhánh chức năng

Các nhánh chức năng là nơi lưu trữ source code của các chức năng được phát triển bởi các team, thành viên khác nhau trong dự án.

Chi tiết về các trường hợp đã đưa ra

Hot fixes

Sau khi chúng ta release version mới, đã merge source code vào master và tag với 1.0, nhưng do phát hiện lỗi nghiêm trọng nên đội dự án cần tạo nhánh hot fix mới dựa vào source code được tag 1.0 trên master để tiến hành sửa lỗi. Quá trình này thường được các thành viên có kinh nghiệm trong dự án thực hiện vì do tính gấp gáp cũng như mức độ rủi ro khá cao. Sau khi hoàn thành hot fix, thực hiện các công đoạn test sản phẩm cần thiết, chúng ta sẽ tiến hành release bản mới ngay v1.1 và tag lại với tag 1.1 để lưu vết. Các bạn đừng quên merge code của hot fix về nhánh dev để chuẩn bị cho lần release tiếp theo.

Chuẩn bị release

Khi quá trình phát triển chức năng đã hoàn thành, chúng ta cần chuẩn bị một nhánh code để release một phiên bản mới, nhánh này sẽ được lấy từ nhánh dev với commit mong muốn, sau khi tách xong nhánh release, quá trình kiểm thử sản phẩm chuẩn bị release sẽ được tiếp tục trên nhánh mới đó, quá trình dev vẫn tiếp tục ở nhánh dev. Nếu trong quá trình kiểm thử sản phẩm chuẩn bị release mà phát hiện lỗi thì chúng ta tiến hành fix lỗi như làm với hot fix, các commit  sẽ được đưa vào nhánh release và nhánh dev cho các lần release kế tiếp.

Phát triển tính năng mới

Một dự án bạn phát triển sẽ có nhiều người tham gia, và nhiều chức năng khác nhau, nên khi nhóm bạn phát triển một chức năng mới thì sẽ lấy code từ nhánh dev chính để phát triển chức năng dự án cần. Sau khi source code mới đã pass hết toàn bộ test cases cần thiết, chúng ta sẽ tiến hành merge ngược lại nhánh dev.

Các nhánh chức năng có thể có các nhánh con của nó tùy vào độ lớn của chức năng đang phát triển hay chỉ là một nhánh đơn dựa vào nhánh dev chính.

Như trong hình, chức năng mới được tách ra từ commit thứ 3, được phát triển với 3 commits, sau khi hoàn thành sẽ merge trở lại nhanh dev chính. Trong quá trình team phát triển chức năng mới, các team khác vẫn chạy và code của các team đó vẫn được merge vào nhánh dev sau khi họ hoàn thành.

Kết luận

Bài viết đã chia sẻ về một quy trình tổ chức, quản lý source code ở các dự án tác giả đã tham gia. Tùy vào dự án, bạn có thể có mô hình khác phù hợp hơn. Nhưng có một điểm bạn cần chú ý khi trao quyền cho các nhóm, bạn cần hạn chế quyền truy cập vào các nhánh chính, nhánh chung ở mức thấp nhất có thể. Với các nhánh đó chỉ cấp quyền write/read cho một số người nhất định, tránh trường hợp mất toàn bộ source code mà không có cách nào lấy lại được.

Chúc bạn thành công!

Trần Hữu Lập – FPT Software

nguồn: techinsight.com.vn

Trả lời

Close Menu