Dậy sớm review task có chút kinh nghiệm trong đầu lôi ra ăn mày quá khứ 😃

Đúng là ai cũng mắc sai lầm rồi mới “may ra” tốt lên được. Ai đứng trên vai thằng khổng lồ thì chắc đỡ hơn chút, đọc mấy cái note nhỏ này của tôi biết đâu giúp ích được mọi người khi đang gặp phải hẹ hẹ hẹ

Tôi đã từng là người đi theo GitFlow (hơi máy móc). Rồi sau đó là Trunk-based. Rồi sau đó là những buổi tranh luận với team chỉ để quyết định… dùng nhánh gì

Sau vài lần release lỗi toang, rollback ngược commit tôi mới ngộ ra một điều là chẳng ai cần GitFlow hay Trunk-based cả. Cái mọi người cần là merge code mà không phá nát production.

Nhiều team đang tôn thờ quy trình thay vì giải quyết vấn đề

Mọi người thích hỏi:

• “Team mình nên dùng GitFlow hay trunk?”
• “Feature branch dài bao lâu thì hợp lý?”
• “Release branch có cần không?”

Tôi xin hỏi lại:

• “Code của bạn merge vào main có gây lỗi không?”
• “Team bạn có biết cách test feature như thế nào trước khi lên production?”
• “Bạn rollback được không nếu deploy xong mà production lỗi?”

Nếu mấy cái này bạn chưa trả lời được thì gitflow hay trunk-based đều là mớ giáo điều vô nghĩa. Nói thế chứ anh em có kinh nghiệm trải qua rồi thì thấy nhẹ không ấy mà 😀

GitFlow đẹp trên giấy, tệ khi team deploy mỗi ngày

GitFlow sinh ra cho thời waterfall: release mỗi tháng, có QA, có staging, có người ngồi test.

Ngày nay, với microservices, CI/CD, release hàng chục lần/ngày thì bạn giữ develop, release, hotfix, main cùng lúc là một cơn ác mộng.

• Merge chéo branch => conflict mệt nghỉ
• Hotfix vào production xong lại phải cherry-pick về develop
• QA test trên release branch, dev quên sync lại => lỗi sống dai qua nhiều phiên bản

GitFlow không scale nổi cho team vừa nhanh, vừa nhiều service.

Trunk-based không thần kỳ như người ta nói

Nghe thì hay:

“Mọi người commit vào main, CI tự test, feature flag bật/tắt tùy ý.”

Nhưng hãy thử áp dụng vào team có 8 người, mỗi người làm một phần, chưa có test coverage đủ, CI chạy 15 phút mà fail thì không ai biết vì… quên bật notify.

Bạn merge vô main, CI pass, deploy rồi lỗi production.

Team rollback vội => lòi ra là có 2 feature chưa hoàn thiện cũng vừa merge.

Rollback thế nào đây?

Trunk-based chỉ hiệu quả khi team bạn có discipline cao, CI/CD bài bản, test đầy đủ và feature flag tốt. Không thì đó là chiếc bẫy cám dỗ.

Cái mọi người thực sự cần là quy trình an toàn để merge code

Quên nhánh đi, tập trung vào thứ này trước:

1. Mỗi PR phải có test case và staging preview. Không test => không merge.

2. Feature nhỏ, không phụ thuộc – hoặc có flag bật tắt. Merge feature đang làm dở là tội ác.

3. CI/CD báo lỗi thì toàn team phải dừng tay fix. Một người lười fix lỗi test là kéo cả team chết chìm.

4. Rollback dễ hơn release. Có thể rollback trong 1 phút là yêu cầu bắt buộc.

Khi bạn có những cái này, xài GitFlow cũng được, trunk cũng được, hay thậm chí dùng 1 cái nhánh duy nhất cũng được. Quan trọng là merge code không phá.

Thế thôi nhỉ

Mọi người hỏi nên dùng nhánh gì, nhưng không ai hỏi “làm sao để deploy an toàn?” Chúng ta không cần thêm nhánh, chúng ta cần bớt lỗi.

Lập trình giỏi không nằm ở flow git bạn chọn. Nó nằm ở chỗ bạn có thể viết code, test nó, merge vào, deploy lên, và… đi ngủ mà không bị gọi on-call.

Tôi chọn cái đó.