Git đã trở thành hệ thống quản lý phiên bản được sử dụng nhiều nhất trên thế giới, bởi vì sự mạnh mẽ mà Git mang lại. Có nhiều mô hình luồng quy trình quản lý Git khác nhau, nhưng Ad sẽ giới thiệu với các bạn mô hình luồng Git mà Ad cảm thấy hiệu quả nhất, đó là luồng quản lý git-flow.
Tóm Tắt
Các nhánh chính
Repo trung tâm (thường là repo của công ty) sẽ chứa các nhánh chính là
- master: nhánh chính chứa source code ổn định, đã được kiểm tra và có thể triển khai lên production.
- develop: nhánh chính chứa source code mới nhất.
Ngoài ra, trong trường hợp có các bên liên quan như QA, khách hàng tham gia vào, mà cần phát triển gấp, thì có thể tạo thêm các nhánh chính khác như qa, staging.
Lưu ý: tất cả các nhánh chính này đều được bảo vệ để không cho commit trực tiếp lên và tránh xóa nhầm.
Các nhánh hỗ trợ
Bên cạnh các nhánh chính, sẽ có các nhánh hỗ trợ để cho team member có thể làm việc song song, dễ dàng tracking theo features, chuẩn bị cho release hoặc fix nhanh các vấn đề production. Các nhánh hỗ trợ này sẽ bị xóa đi sau khi dùng.
Các nhánh hỗ trợ này được chia thành các loại:
- Feature branches
- Release branches
- Hotfix branches
Feature branches
- Tách từ: develop
- Merge vào: develop
- Quy tắc đặt tên: tự do, ngoại trừ master, develop, release-*, hotfix-*
Feature branches (các nhánh tính năng) được sử dụng để phát triển các tính năn
g mới phục vụ cho release sau này. Mỗi tính năng sẽ là một nhánh riêng, được tạo từ source mới nhất của develop và sau khi phát triển xong sẽ được merge vào develop.
Release branches
- Tách từ: develop
- Merge vào: develop và master
- Quy tắc đặt tên: release-*
Release branches được sử dụng để chuẩn bị cho release bản production mới. Tất cả các công việc cuối cùng trước khi release sẽ được thực hiện ở đây, ngoài ra còn để fix nốt các bugs lẻ tẻ, chuẩn bị meta-data (version number, build dates, etc..). Nhờ việc tách nhánh ra khỏi develop, chúng ta có thể tiếp tục phát triển các features cho đợt release khác một cách bình thường.
Thời điểm được lựa chọn để tách nhánh từ develop là khi develop phản ánh được trạng thái mong muốn cho việc release mới. Ít nhất lúc đó tất cả các features dành cho đợt release phải được merge vào develop rồi. Những features nhắm đến các lần release sau thì chưa được merge vào, phải đợi sau khi tách nhánh.
Chúng ta sẽ tiến hành đánh version theo rule của dự án ngay sau khi tạo release branch.
Branch mới này sẽ tồn tại cho đến khi việc release được thực hiện gọn ghẽ. Trong khoảng thời gian đó, có thể thực hiện fix bugs ở branch này, tuy nhiên nghiêm cấm việc bổ sung feature mới lên đó. Tốt nhất nếu có features mới thì hãy merge vào develop, và đợi đợt release sau.
Khi source code trên release branch sẵn sàng để release, đầu tiên, phải merge vào master, sau đó phải đc merge lại vào develop để những lần release sau cũng chứa những thay đổi ở lần này.
Hotfix branches
Tách từ: master- Merge vào: develop và master
- Quy tắc đặt tên: hotfix-*
Hotfix branches cũng giống release branches ở chỗ được sử dụng để chuẩn bị cho việc release production mới, chỉ khác ở chỗ là ko có plan từ trước. Khi có một bug nghiêm trọng trên bản production cần được giải quyết ngay lập tức, một hotfix branch sẽ được tách ra từmaster và được đánh version để nhận biết.
Ưu điểm của việc tách nhánh này ở chỗ các team members khác có thể tiếp tục công việc ở develop trong khi những người khác có thể tập trung vào fix bug của production.
Sau khi kết thúc sửa lỗi, những thay đổi phải được merge lại master, đồng thời cũng phải merge vào develop để ngăn lỗi xảy ra ở những lần release sau.
Tuy nhiên, có một điểm cần lưu ý rằng: khi đang tồn tại một release branch thì cần phải merge hotfix vào release branch đó, thay cho develop.
Xử lý conflict thế nào cho đúng
Khi code bị conflict, bạn có thể xử lý bằng cách merge, nhưng cách đúng hơn cả là sử dụng rebase. Rebase sẽ giúp cho luồng Git graph được rõ ràng và tường minh, ngoài ra, Merge Request của bạn sau khi sửa sẽ không bị lẫn với Merge Request của người khác, giúp cho Leader của bạn dễ review hơn.
Cách làm như sau:
Nhánh tính năng là nhánh feature-1
Nhánh code chính là nhánh develop (hoặc có thể là 1 nhánh release, hotfix bất kỳ)
- Chuyển sang nhánh develop và checkout code mới nhất về
git checkout develop git pull
- Chuyển sang nhánh feature-1 và rebase với nó với nhánh develop.
git checkout feature-1 git rebase develop
- Kiểm tra và sửa code bị conflict. Nếu có nhiều commit bị conflict thì sau mỗi lần sửa conflict sẽ chạy tiếp git rebase –continue
- Đẩy code hoàn chỉnh lên nhánh feature-1
git add file git rebase --continue git commit -m "id: Fix conflict file abc" git push origin feature-1
- Tạo Merge request vào nhánh develop
- Nếu trong quá trình rebase mà bị lỗi, bạn có thể hủy bằng cách
git rebase --abort
Lưu ý: Nếu như bạn đã có sẵn Merge Request rồi thì bạn chỉ cần đẩy code lên nhánh feature-1 ở repo trung tâm là commit sẽ tự động được đưa vào Merge Request.
Bạn nên thực hiện add theo file (tránh git add .) để kiểm soát được những file mà mình sẽ add code lên.
Lời kết
Trên đây là mô hình luồng Git mà Ad thấy hiệu quả và thành công nhất. Để quản lý và sử dụng Git hiệu quả, bạn phải nắm chắc được chiến lược và quy trình làm việc với nó, trước khi nắm thêm được các kỹ thuật xử lý đặc biệt khác. Ở dưới đây là 19 kỹ thuật khi gặp sự cố với Git mà bạn có thể dùng để xử lý sự cố của mình.
Tham khảo:
https://nvie.com/posts/a-successful-git-branching-model/
https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
https://viblo.asia/p/19-bi-kip-ban-co-the-dung-khi-pham-sai-lam-voi-git-dWrvwdmPRw38
Tham khảo các bài viết khác trong Series Trở thành Full-stack Developer
