[Git] Xây dựng Gitflow cho dự án thực tế

Cũng như nhiều thứ tuyệt vời khác trong cuộc sống, Git ra đời từ một chút của sự huỷ diệt/phá sản/kết thúc có tính sáng tạo và sự tranh cãi nảy lửa. Nhân của Linux là một dự án phần mềm mã nguồn mở của một phạm vi khá lớn. Trong phần lớn thời gian bảo trì của nhân Linux (1991-2002), các thay đổi của phần mềm được truyền đi dưới dạng các bản vá và các tập tin lưu trữ. Vào năm 2002, dự án nhân Linux bắt đầu sử dụng một DVCS độc quyền có tên là BitKeeper.

Vào năm 2005, sự hợp tác giữa cộng đồng phát triển nhân Linux và công ty thương mại phát triển BitKeeper bị phá vỡ, và công cụ đó không còn được cung cấp miễn phí nữa. Chính điều này đã thúc đẩy cộng đồng phát triển Linux (chính xác hơn là Linus Torvalds, người sáng lập ra Linux) phát triển công cụ của riêng họ dựa trên những bài học từ việc sử dụng BitKeeper. Một số mục tiêu của hệ thống mới được vạch ra như sau:

• Nhanh
• Thiết kế đơn giản
• Hỗ trợ tốt cho "phát triển phi tuyến tính" (non-linear development) - (hàng ngàn nhánh song song)
• Phân tán toàn diện
• Có khả năng xử lý các dự án lớn giống như nhân Linux một cách hiệu quả (về mặt tốc độ và khối lượng dữ liệu)

Kể từ khi ra đời năm 2005, Git đã tiến hoá và phát triển toàn diện để dễ dàng sử dụng hơn, tuy thế các tiêu chí ban đầu vẫn được đảm bảo. Nó nhanh một cách đáng kinh ngạc, vô cùng hiệu quả với các dự án lớn, và một hệ thống phân nhánh không thể tin được cho phát triển phi tuyến tính (xem Chương 3).

• Dựa trên mô hình của GitHub Flow. Về mô hình GitHub Flow, có thể xem bản hướng dẫn gốc của GitHub.
• Dựa vào yêu cầu của mỗi dự án, skill của các members trong dự án mà mô hình này có thể được sửa lại cho phù hợp với từng dự án.
• Không có 1 mô hình tuyệt đối chính xác hay đúng đắn. Tất cả chỉ là tương đối.

Với các dự án quá cũ, có cách vận hành gitflow khác thì không cần phải chuyển qua mô hình này.

Vai trò của các branch

master

• Luôn ở trạng thái có thể deploy.
• Không bị fail auto test
  • nếu dự án có yêu cầu dùng auto test
  • nếu có vấn đề gì thì phải ưu tiên fix đầu tiên
• Không được commit/push trực tiếp vào branch này. Branch master phải được bảo vệ bằng chức năng protected branchs của GitHub.

feature-XXX

• Tách ra từ branch master
• XXX là id của backlog (hoặc redmine, github issue, … tuỳ theo dự án)
• Dù chỉ có 1 commit cũng phải tạo pull request. Các pull request khi tạo phải có tiền tố [WIP] ở trước. Sau khi được hoàn thiện và sẵn sàng review thì bỏ tiền tố này đi. Các pull request phải hướng về master.

feature-XXX-YYY

• Được tách ra từ branch feature-XXX
• YYY là tên người làm.
• Chỉ dùng trong trường hợp có nhiều hơn 1 người cùng dev 1 chức năng.
• Dù chỉ có 1 commit cũng phải tạo pull request. Các pull request khi tạo phải có tiền tố [WIP] ở trước. Sau khi được được hoàn thành và sẵn sàng review thì bỏ tiền tố này đi. Các pull request phải hướng về feature-XXX.

Review

• Khi tạo 1 branch mới và có commit mới thì bắt buộc phải tạo pull request và thêm prefix [WIP].
• Tất cả các pull request phải được review.
  • Sau khi hoàn thiện xong chức năng và sẵn sàng review thì bỏ [WIP] đi và assign lại cho leader.
• Sử dụng các công cụ chatwork/slack để yêu cầu được review.
• Sau khi review xong thì leader merge vào và xoá branch đó đi.
  • Nếu có yêu cầu phải sửa thì comment vào và assign ngược lại cho member.
  • Leader sau khi review xong cần phải comment lại để cho members được biết. Ví dụ như LGTM, +1:, …

Deploy

• Nếu có thay đổi trong master thì tự động deploy.
  • Quản lý bằng Jenkins / CircleCI / Drone
  • Bên web/server : sử dụng các tools deploy tự động như capistrano để tiết kiệm thời gian và giảm rủi ro.
  • Về app thì sử dụng các tools như deploygate, testflight để deploy.

Có nhiều dự án sử dụng chức năng tự động deploy của CircleCI rất hiệu quả. Cách làm này tiết kiệm thời gian và cải thiện workflow trong team.

• Sử dụng branch release chuyên để deploy lên production.
• Khi deploy lên prd, tạo pull request từ branch master vào branch release. Branch release phải được bảo vệ bằng chức năng protected branchs của GitHub.
• Xác nhận sự thay đổi, nếu không có vấn đề gì thì merge vào release.
• Sau khi merge xong thì deploy lên server prd. Khuyến khích dùng deploy tự động.

• Các lỗi khẩn cấp này không muốn gặp nhưng đôi lúc vẫn xuất hiện. Lý do vì môi trường production thường khác môi trường staging. Prd thường có ELB, S3, biến môi trường khác biệt, …
• Các lỗi này cần phải fix ngay lập tức, thường thì không có thời gian để trải qua đủ các quy trình deploy.

hotfix-XXX

• Tách ra từ branch release
• XXX là ID của backlog hoặc redmine, …
• Sau khi làm xong thì gửi pull request vào release, merge và deploy lên.
• Gửi pull request vào master và merge.

Phần này mình sẽ giải thích về mô hình git của dự án sau khi đã release phase 1st. Mỗi dự án thường chia thành nhiều phase. Mỗi phase có những tính năng độc lập với nhau. Vì sự độc lập này mà mô hình git cũng có ít nhiều thay đổi cho phù hợp.

Vai trò của các branch

master

• Là version mới nhất cho phase 2nd
• Ngoài ra tất cả đều giống như phần trên.

release

• Tại thời điểm kết thúc phase 1st thì được tạo branch release từ branch master.
• Sau khi kết thúc phase 2nd thì merge vào master.

feature-XXX (branch thực hiện các chức năng của phase 2nd）

• Tách ra từ branch master
• Ngoài ra tất cả đều giống như phần trên.

bug-fix-XXX (branch fix bugs cho phase 1st）

• Tách ra từ branch release
• XXX là ID của backlog, redmine, …

• GitFlow trong thực tế