Dân trong ngành thì chắc cũng chả ai lạ gì khái niệm về VCS (Version Control System), hiểu đơn giản là để quản lý sự thay đổi của source code nói riêng và file nói chung trong quá trình phát triển dự án.
Hiện tại thì SVN và Git là 2 VCS được sử dụng nhiều nhất. SVN và Git là đại diện cho 2 trường phái của VCS gọi là Centralized và Distributed Version Control. Xu thế hiện nay thì SVN đang được chuyển đổi dần sang Git. Để sử dụng được Git để quản lý source code thì khá là dễ. Bạn chỉ cần hiểu được 1 vài khái niệm cơ bản, như remote, branch, commit, pull hay push. Nhưng dùng Git sao cho hiệu quả, tận dụng được các tính năng, các điểm mạnh của Git so với các VCS khác thì lại là 1 chuyện khác.
Trong bài này tôi xin được giới thiệu 1 số quy trình làm việc sử dụng Git, tạm gọi là Git Workflow, có thể nói là cơ bản và được dùng nhiều nhất hiện nay.
- Centralized
Đây là workflow cơ bản nhất, với 1 branch duy nhất, mọi người trong team đều làm việc chung trên này. Nó giống hệt với svn nói riêng và các centralize version control khác. Vậy nên nó ko tận dụng được hết những tính năng cũng như ưu điểm của git. Mình nghĩ flow này áp dụng cho những team mới áp dụng git, những dự án nhỏ, có vòng đời phát triển ngắn. Hoặc flow này có thể áp dụng như giai đoạn trung gian của việc chuyển dự án từ SVN sang Git.
- Feature branch workflow
Nếu như Centralized Workflow giúp các bạn quen với các command của Git, cũng như quy trình pull -> add -> commit rồi push thì flow này sẽ giúp các bạn thấy được sự khác biệt của Git so với SVN. Flow này sẽ hỗ trợ rất nhiều trong teamwork, khi mà nhiều developer cùng phát trển nhiều tính năng trong 1 dự án 1 lúc.
Để nắm được flow này thì đầu tiên bạn phải hiểu được 1 khái niệm khá cơ bản trong Git, đó là branch.
Có thể đọc về khái niệm này tại đây: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Quay lại với Feature branch flow, ý tưởng chính của flow này là việc, khi 1 developer implement 1 tính năng của dự án, họ sẽ làm việc (code) trên 1 feature branch riêng, chứ không làm việc trên master. Khi đó master branch sẽ là 1 base branch. Việc tạo branch mới, sẽ checkout từ master ra. Và nguyên tắc là chỉ những thứ gì đúng đắn, được đảm bảo qua test, review code, … mới được đưa vào master. Lấy ví dụ, 2 dev A và B implement 2 tính năng xxx và yyy cùng lúc, khi đó A sẽ code trên branch xxx và B sẽ code trên branch yyy. Khi implement xong, test đủ thứ và OK, developer sẽ tạo 1 pull request (merge request) từ feature branch của mình vào master. Pull request được chấp nhận, thì những commit từ feature branch này, sẽ được đưa vào master và coi như trở thành base code.
Trong trường hợp khi mà A hoàn thành trước và branch xxx được merge vào master. Khi B hoàn thành và muốn publish code của mình vào master, có thể sẽ xảy ra trường hợp conflict với những commit từ branch xxx. Lúc này, để pull request của mình có thể merge đc, B cần xử lý conflict.
Có 1 khái niệm khá hay trong flow này là pull request. Ngoài việc để merge 1 feature branch và branch chính, pull request còn giúp cho team leader hay cả team review lại code của 1 thành viên trong nhóm. Qua đó coi như code được kiểm duyệt thêm 1 lần trước khi đưa vào master. Các Git cloud server hiện nay hỗ trợ rất tốt việc này, như Github hay Bitbucket.
Feature branch là 1 flow linh hoạt, ứng dụng được nhiều điểm mạnh của git, thích hợp cho những dự án phát triển với team nhỏ và vừa. Nhưng với những dự án lớn hơn, những team lớn hơn, hay đơn giản là khi cần thiết phải chia role cho các branch, chứ ko đơn thuần là chỉ có branch master và các feature branch. Nó hướng chúng ta đến flow tiếp theo dưới đây: Gitflow Workflow.
- Gitflow workflow
So với feature branch, thì flow này sẽ có nhiều hơn 1 branch là base branch. Như ở hình trên sẽ có 2 branch có vai trò này. Nó thích hợp cho việc bạn sẽ có 1 branch cho server production, 1 branch cho việc maintenance mà vẫn có thể tận dụng được các lợi ích của Feature branch flow như pull request, …
Hình dưới đây sẽ cụ thể hơn cho việc hình dung việc flow hay làm việc như nào:
Master vẫn luôn được đảm bảo là branch ổn định và ít lỗi nhất. Khi có lỗi, hotfix được checkout từ master ra để sửa. Trong khi đó, các developer sẽ làm việc trên develop và các feature branch giống như Feature branch flow.
- Forking workflow
Nhìn vào ảnh trên mọi người có thể hiểu 3 cái hộp database bên trên là 3 cái server-side repository khác nhau. Có nghĩa là khác với 3 flow ở trên tất cả developer làm việc trên local nhưng dùng chung 1 server side repos. Ở flow này, mỗi người sẽ có 1 server side repos khác nhau và thoải mái phát triển trên đó. Điểm khác biệt ở đây là mọi người có thể tự do lựa chọn việc đi theo 1 con đường riêng, hoặc quy tụ với con đường chính (khi merge repos chính) sau khi có 1 quãng tự đi rồi. Cũng có thể đi chung đường với 1 thằng dev khác (merge repos của họ vào của mình) mặc kệ repos chính nó đang có gì ^^
Chúng ta có thể thấy flow này đang được áp dụng ở cloud mã nguồn mở có thể nói là lớn nhất hiện nay: Github. Mọi người có thể fork 1 repo trên này và phát triển thêm theo ý của mình. Sau đó nếu muốn đóng góp ngược lại vào repos chính thì có thể tạo pull request, người owner của repos ban đầu có thể kiểm tra và merge repos của bạn vào repos chính.
Xin hết bài viết về 4 git workflow phổ biến nhất hiện nay.
Reference: https://www.atlassian.com/git/tutorials/comparing-workflows
COMMENTS