GitFlow, GitHub Flow… và mấy kiểu Branching Strategy khác

Code team mà không có luật chơi thì đúng là thảm họa, conflict sml là chuyện như cơm bữa. Sau bao lần vật vã với đống nhánh loạn cào cào, mình mới thấm thía cái gọi là branching strategy nó quan trọng cỡ nào. Nó không chỉ là mấy cái tên branch, mà là workflow để cả team phối hợp nhịp nhàng, code không đánh nhau. Dưới đây là vài kiểu phổ biến, mình tóm gọn lại theo góc nhìn của dân dev mình, biết đâu anh em lại tìm được chân ái cho team.

GitFlow: Ông lớn trong làng, cấu trúc thì khỏi phải bàn, đúng kiểu chuẩn sách giáo khoa với 5 loại branch. Team nào to, dự án lớn, release theo lịch cứng thì ngon, chứ team nhỏ cần đi nhanh mà vác cái này vào thì đúng là overkill.

GitHub Flow: Anh bạn này thì đơn giản, dễ thở: cứ main với mấy cái branch feature sống ngắn hạn. Code xong, mở PR, CI pass, anh em approve là bụp phát vào main rồi ship hàng luôn. Team nào CI/CD xịn sò thì đây đúng là chân ái.

GitLab Flow: Thằng này là con lai giữa GitFlow và GitHub Flow. Cái hay của nó là map các branch thẳng với các môi trường deployment staging, production. Anh em nào dùng hệ sinh thái của GitLab thì nên nghía qua, tích hợp ngon nghẻ lắm.

Environment Branching: Mỗi môi trường dev, qa, prod một branch riêng. Cách này hơi cổ, dễ làm code các môi trường bị lệch pha. Team nào quy trình còn manual nhiều thì có thể vẫn dùng, chứ thời auto deploy thì nên cân nhắc kỹ.

Trunk-Based Development: Dành cho các team tay to, thích chơi hệ hardcore. Anh em dev commit thẳng lên main luôn, không nói nhiều. Nghe thì yolo thật, nhưng để làm được thì hệ thống test auto phải bá đạo, và dev phải cứng tay.

Release Branching: Đây là cứu cánh cho các project phải support nhiều version cùng lúc v1.x, v2.x. Nó giúp anh em vừa code feature mới cho version sau, vừa fix bug cho version cũ mà không bị loạn.

Feature Branching: Workflow có phải là quốc dân của anh em dev. Cứ có task mới là phệt ra một branch. Cách này dễ thở, dễ quản lý, nhưng tech lead nhớ nhắc anh em merge nhánh thường xuyên nhé, để lâu là ăn conflict mệt nghỉ đấy.

Forking Workflow: Anh em nào chơi hệ mã nguồn mở thì chắc chắn biết workflow này. Contributor sẽ fork repo về, code trên repo của họ rồi tạo Pull Request. Cách này giữ cho repo gốc luôn sạch sẽ và an toàn.

Chốt lại thì không có workflow nào là silver bullet cả. Anh em cứ xem xét size team, độ phức tạp của project và văn hóa của team mình để chọn ra cái phù hợp. Quan trọng nhất là tech lead phải chốt được một luật chơi và cả team phải follow, thế là code ngon, dev vui.