Ý tưởng chính nằm sau Feature Branch Workflow là việc phát triển một chức năng cần được thực hiện ở một nhánh riêng biệt chứ thay vì nhánh master. Việc đóng gói này giúp nhiều dev có thể cùng phát triển một chức năng dễ dàng hơn mà không ảnh hưởng gì đến code chính của nhóm. Nó cũng có nghĩa là nhánh master sẽ không bao giờ có chứa code bị lỗi, điều này mang lại lợi ích lớn cho việc tích hợp liên tục trên các môi trường.

Đóng gói việc phát triển chức năng tận dụng được công dụng của pull request (PR) – một cách thể thảo luận về những dòng code thay đổi và xin sự đồng ý của những dev khác trước khi merge vào master. Hoặc là nếu bạn cảm thấy khó khăn hoặc bế tắc ở đâu đó khi phát triển chức năng mình phụ trách, bạn có thể tạo một PR để hỏi thăm đồng nghiệp xem nên làm thế nào. Mấu chốt là, PR giúp team có thể comment về code của mọi người một cách cực kì dễ dàng.

Git Feature Branch Workflow tập trung chính vào mô hình nhánh, nhằm hướng dẫn về cách quản lý và tạo nhánh.

How it works

Chúng ta bắt đầu với một central repository, và nhánh master thể hiện quá trình phát triển chính thức của project. Thay vì commit trực tiếp vào nhánh master ở local, dev tạo nhánh mới mỗi lần họ bắt đầu phát triển một chức năng mới. Các nhánh chức năng nên có nên cụ thể, ví dụ animated-menu-items hoặc issue-#106 nhằm thể hiện rõ ràng chức năng mà nhánh phụ trách. Về mặt kĩ thuật của Git, nhánh master và các nhánh chức năng (feature branch) không có gì khác biệt, do đó dev có thể edit, stage, commit thay đổi vào nhánh chức năng một cách bình thường.

Hơn nữa, nhánh chức năng có thể được đẩy lên central repo để share cho những dev khác mà không làm ảnh hưởng gì đến code chính thức. Vì nhánh master là nhánh “đặc biệt” duy nhất, lưu thêm một vài nhánh chức năng trên central repo không gây ra vấn đề gì cả. Và đó cũng là một cách thuận tiện để back up code local của mọi người. Phần dưới đây sẽ trình bày life-cycle (vòng đời) của một nhánh chức năng.

Start with the master branch

Tất cả các nhánh chức năng cần được tạo từ code mới nhất của project. Hướng dẫn này giả thiết rằng code mới nhất được duy trì và cập nhật ở nhánh master.

git checkout 
master
git
 fetch origin
git reset --hard origin/
master

Các câu lệnh trên chuyển nhánh code ở local sang nhánh master, kéo code mới nhất (của nhánh master) về và đưa code về trạng thái update cuối cùng ở nhánh master (những local changes sẽ bị xoá đi)

Create a new-branch

Tạo nhánh mới ở local:

git checkout -b 
new
-feature

Cờ -b bảo Git là hãy tạo nhánh mới tên new-feature nếu mà nó chưa tồn tại.

Update, add, commit

Ở nhánh này, ta thực hiện việc coding như thường lệ và commit:

git status
git 
add
 <some-file>
git commit

Push feature branch to remote

Đưa nhánh chức năng vừa tạo ở local lên trên central repo bằng lệnh:

git 
push
 -u 
origin
 
new
-
feature

Cờ -u biến nhánh này thành remote tracking branch. Sau này dev đẩy code lên chỉ cần dùng lệnh git push mà không cần thêm parameter nào. Muốn nghe nhận xét về những thay đổi trong nhánh này, dev cần tạp PR trên repo được quản lý bởi một dịch vụ quản lý repo như Bitbucket, Github, Gitlab… Từ đây, dev có thể thêm reviewer, lắng nghe nhận xét của họ, và đảm bảo mọi thứ ok trước khi merge.

Resolve feedback

Nếu đồng nghiệp của dev có bình luận, góp ý sửa đổi, dev cần sửa nó ở local, commit và push lên. Những thay đổi của dev sẽ có ở trong PR.

Merge your pull request

Trước khi merge code, có thể dev sẽ phải giải quyết một số conflict nếu mà có ai đó đã thay đổi nhánh master. Khi PR đã được chấp thuận và không còn conflict nữa, dev có thể merge PR để thêm code mình đã thay đổi vào nhánh master.

Pull requests

Bên cạnh việc khiến quá trình phát triển chức năng trở nên độc lập, nhánh giúp team có thể thảo luận về những thay đổi thông qua PR. Một khi ai đó hoàn thành chức năng mình phụ trách, họ không được merge ngay vào master. Thay vào đó, họ đẩy nhánh chức năng lên central server và tạo một PR để được chấp thuận merge từ đồng nghiệp. Điều này là cơ hội để các dev khác đánh giá code mới trước khi nó trở thành main codebase.

Code review là lợi ích lớn nhất mà PR mang lại, nhưng PR lại được thiết kế để trở thành một cách chung để trao đổi về code. Có thể coi mỗi PR như là một cuộc thảo luận về một branch cụ thể. Ta có thể sử dụng nó sớm trong quá trình phát triển. Ví dụ, nếu một dev cần sự giúp đỡ về 1 tính năng cụ thể, tất cả những gì dev cần làm là tạo 1 cái PR. Những bên liên quan sẽ nhận được thông báo về PR đó (một cách tự động) và họ có thể thấy câu hỏi của dev ngay cạnh những commit liên quan.

Một khi PR được chấp thuận, việc đưa code lên nhánh master tương tự như với Centralized Workflow. Đầu tiên, dev cần đảm bảo nhánh master ở local giống với nhánh master ở upstream. Sau đó, merge nhánh của mình vào nhánh master ở local, mà đẩy nhánh master vừa mới được update ở local lên central repo.

Example

Ví dụ dưới đây chỉ ra một trường hợp feature branching workflow được sử dụng.

Mary begins a new feature

Trước khi bắt đầu code, Mary cần tạo 1 nhánh riêng cho chức năng mình phụ trách bằng lệnh sau:

git checkout -b marys-feature master

Lệnh này tạo ra một nhánh tên là marys-feature từ nhánh master. Trên nhánh này, Mary edit, stage, commit để phát triển chức năng của mình.

Mary goes to lunch

Trong buổi sáng Mary đã commit được vài lần rồi. Trước khi cô ấy đi ăn trưa, cố ấy muốn đưa nhánh của cô ấy lên central repo. Việc này vừa giúp backup, vừa giúp chia sẻ code với dev khác nếu họ cùng phát triển chức năng này với Mary.

git push -u origin marys-feature

Lệnh này giúp đưa nhánh marys-feature lên central repo (origin), cờ -u khiến nhánh này thành remote tracking branch. Nó có nghĩa là sau này Mary có thể dùng lệnh git push mà không cần thêm tham số nào đằng sau nữa.

Mary finishes her feature

Sau bữa trưa, Mary tiếp tục làm việc và hoàn thiện tính năng của mình. Trước khi merge vào master, cô ấy cần tạo 1 pull request để cả team biết được là cô ấy đã làm xong rồi. Nhưng trước tiên, cần phải đẩy toàn bộ code ở local lên central repo đã:

git push

Sau đó, cô ấy tạo PR trên Git GUI (Graphic User Interface) của mình, xin chấp thuận để được merge nhánh marys-feature vào master, teammate của cô ấy sẽ được thông báo tự động.

Bill receives the pull request

Bill thấy PR vừa tạo và review nhánh marys-feauture. Anh ấy muốn thay đổi một vài cái trước khi merge nhánh này vào master, nên anh ấy và Mary có trao đổi 1 chút thông  qua PR Mary tạo.

Mary makes the changes

Mary thêm những thay đổi với những thao tác giống như cô ấy làm ban đầu: edit, stage, commit, push lên central repo. Những thay đổi của cô ấy sau khi push lên central repo cũng sẽ xuất hiện trong PR cô ấy tạo trước đó và Bill có thể tiếp tục comment trên đó.

Nếu Bill muốn, anh ấy có thể kéo nhánh marys-feature về, code trên đó và đẩy lên central repo. Những commit anh ấy thêm cũng sẽ xuất hiện ở trong PR Mary đã tạo.

Mary publishes her feature

Khi Bill đã chấp thuận PR của Mary, code cần được merge vào master:

git checkout master
git pull
git pull origin marys-feature
git push

Quá trình này thường tạo ra một merge commit.

Một số GUI sẽ tự thực hiện quá trình merge và đóng PR lại khi mà PR được chấp thuận.

Trong khi đó, John cũng đang làm công việc của mình. Trong khi Mary và Bill làm công việc họ phụ trách, John cũng làm việc ở nhánh riêng và công việc của họ không ảnh hướng đến nhau  do tính độc lập của các branch.

Summary

Git Feature Branch Workflow giúp tổ chức và theo dõi các nhánh ứng với những tính năng nghiệp vụ cụ thể. Các Git workflow khác như Git Forking Workflow và the Gitflow Workflow tập trung vào repo, và có thể tận dụng Git Feature Branch Workflow để quản lý braching model của mình. Một số điểm chính cần nhớ về Git Feature Branch Workflow là:

• Tập trung vào mô hình nhánh.
• Có thể được tận dụng bở những workflow hướng repo khác.
• Thúc đẩy sự công tác của team member thông qua PR và merge review.

Phần 1: So sánh các Git workflow
Phần 2: Centraliezed Workflow
Phần 3: Git Feature Branch Workflow
Phần 4: Gitflow Workflow

 

Advertisement

Share this:

• Twitter

• Facebook

Like this:

Like

Loading…

Related