Khi bạn làm dự án một mình, bạn muốn đặt tên nhánh thế nào cũng được, muốn push thẳng lên main lúc nào cũng xong. Nhưng khi bước vào một dự án lớn với sự tham gia của hàng chục Developer, Tester, DevOps... nếu không có một quy ước chung, Git Graph của bạn sẽ lập tức biến thành một bãi chiến trường vô chính phủ.
Để giải quyết bài toán này, thế giới sinh ra các Git Workflow (Luồng làm việc với Git). Trong đó, Git Flow và GitHub Flow là hai tượng đài lớn nhất. Hãy cùng bật Git Graph lên để xem chúng khác nhau ra sao.
1. Git Flow: Bộ Giáp Bọc Thép Cho Doanh Nghiệp Lớn
Xuất hiện từ năm 2010, Git Flow là mô hình phân nhánh cực kỳ nghiêm ngặt, an toàn và có tính phân hóa cao. Khi nhìn vào một Git Graph chạy theo chuẩn Git Flow, bạn sẽ thấy nó luôn có 2 nhánh sống sót suốt đời dự án chạy song song, kèm theo các nhánh phụ ngắn hạn.
Bản đồ các làn đường trong Git Flow:
- Nhánh main (hoặc master): Nhánh thiêng liêng nhất, chỉ chứa code đã deploy lên Production cho khách hàng dùng. Mỗi nút trên nhánh này thường đi kèm một thẻ dán nhãn phiên bản (Git Tag) như v1.0, v2.0.
- Nhánh develop: Nhánh trung tâm của các Developer. Mọi tính năng mới sau khi làm xong đều phải hội quân tại đây để test tích hợp.
- Các nhánh feature/: Nhánh ngắn hạn, rẽ ra từ develop để làm task riêng, làm xong thì merge ngược lại develop rồi xóa nhánh đi.
- Các nhánh release/: Khi chuẩn bị đem sản phẩm đi bàn giao, một nhánh release sẽ được tách ra từ develop để đội QC/Tester vào đập phá, tìm lỗi và fix trực tiếp trên đó. Khi mọi thứ đã hoàn hảo, nhánh này sẽ được merge vào cả main lẫn develop.
- Các nhánh hotfix/: Nhánh "cứu hỏa". Khi Production đột ngột xảy ra lỗi nghiêm trọng, một nhánh hotfix sẽ được rẽ nhánh trực tiếp từ main, sửa lỗi xong là lập tức merge ngược lại cả main và develop.
Hình ảnh Git Graph: Đồ thị của Git Flow nhìn rất hoành tráng với nhiều làn đường chạy song song dài dằng dặc. Nó cực kỳ phù hợp cho các dự án lớn, làm việc theo kỳ phát hành (Release Cycle) cố định (ví dụ: 2 tuần hoặc 1 tháng release một lần) như hệ thống ngân hàng, app mobile, thương mại điện tử.
2. GitHub Flow: Tay Đua Tốc Độ Của Kỷ Nguyên Agile/SaaS
Nếu Git Flow là một tập đoàn cồng kềnh, cẩn trọng thì GitHub Flow là một startup tinh gọn, linh hoạt. Mô hình này ra đời khi các sản phẩm Web/SaaS lên ngôi, nơi mà tư duy "Continuous Delivery" (Tích hợp và bàn giao liên tục) làm chủ đạo — nghĩa là code xong cái gì là có thể đẩy thẳng lên cho khách hàng dùng ngay trong ngày.
Bản đồ đường chạy của GitHub Flow:
- Chỉ có 1 nhánh duy nhất sống sót suốt đời, đó là main. Quy tắc bất di bất dịch: Code trên main luôn luôn phải chạy được và sẵn sàng deploy bất cứ lúc nào.
- Khi bạn có tính năng mới hoặc cần sửa lỗi? Hãy rẽ nhánh trực tiếp từ main với một cái tên gợi nhớ (ví dụ: feature-login-oauth).
- Code xong, bạn push nhánh đó lên GitHub và tạo một Pull Request (PR) để cả team vào review, thảo luận.
- Sau khi PR được duyệt và test pass, nhánh đó sẽ được merge thẳng vào main và deploy lên Production ngay lập tức. Nhánh phụ bị xóa bỏ hoàn toàn.
Hình ảnh Git Graph: Đồ thị của GitHub Flow cực kỳ tối giản. Nó chỉ là một đường thẳng main trung tâm, thỉnh thoảng có vài nhánh nhỏ nhô ra như những cái rễ cây, rồi lại nhanh chóng cắm ngược vào main chỉ sau vài giờ hoặc vài ngày.
3. Lên Bàn Cân: Chọn Giáp Nặng Hay Chọn Tốc Độ?
| Tiêu chí | Git Flow | GitHub Flow |
|---|---|---|
| Độ phức tạp trên Graph | Rất cao, nhiều đường song song, nhiều Merge Commit. | Rất thấp, gần như là một đường thẳng tuyến tính. |
| Nhánh chính | Chia đôi: main (Production) và develop (Staging). | Chỉ có duy nhất một nhánh main. |
| Tốc độ Ship code | Chậm, phải qua các tầng lọc release/ nghiêm ngặt. | Cực nhanh, deploy liên tục nhiều lần trong ngày. |
| Phù hợp với | Hệ thống Enterprise, App Mobile, Embedded System. | Web Application, SaaS, Dự án mã nguồn mở. |
Lời Kết Cho Chuỗi Series Git Graph
Qua 5 bài viết, chúng ta đã cùng nhau vén màn bí mật đằng sau những đường nét xanh đỏ của Git Graph. Từ việc hiểu bản chất Git là một đồ thị DAG, biết cách cân nhắc giữa sự chân thực của Merge và sự gọn gàng của Rebase, sở hữu tư duy phẫu thuật chính xác của Cherry-pick, biết dọn dẹp nhà cửa bằng Interactive Rebase, và cuối cùng là chọn cho team một Workflow phù hợp.
Hy vọng series này đã giúp bạn thay đổi hoàn toàn góc nhìn về Git: Không còn gõ lệnh theo tâm linh, mà hoàn toàn làm chủ và nhìn thấu lịch sử của dự án. Cảm ơn bạn đã đồng hành cùng mình!
