Git flow - Source control management

DevOps - Git flow - Source control management

Reference:

• A successful Git branching model
• Git-book
• Nhập môn Git

Quy trình làm việc với Git khi phát triển Project

The branching strategy and release management

Branch chính (The main branches)

• master branch - (origin/master): đây là branch chính chứa source code đã sẵn sàng để release cho khách hàng (production-ready state) và là branch được dùng để tạo tag release number.
• develop branch - (origin/develop): đây là branch chính chứa source code với các features và các thay đổi phát triển được phân phối mới nhất (the latest delivered development changes for the next release) cho bản release tiếp theo. Đây cũng là nhánh được dùng để deploy cho QC test. Do đó, code trên nhánh develop phải luôn luôn không chứa những con bug đã từng tồn tại ở những version trước đó.

Khi source code trong nhánh develop chạy ổn định với các features và các thay đổi cần thiết để sẵn sàng release thì tất cả các thay đổi này sẽ được merge về nhánh master và sau đó được tagged với 1 release number.

Các branch hỗ trợ trong quá trình phát triển (Supporting branches)

• Feature branches: feature/* - example: feature/implement-login
• Release branches: release-* - example: release-sprint-01, release-1.0
• Hotfix branches: hotfix-* - example: hotfix-sprint-01, hotfix-1.0

- Không giống như các branch chính, các branch này luôn có thời gian tồn tại nhất định (a limited life time) vì chúng sẽ bị xoá (delete/remove) sau khi được merge vào nhánh chính.

- Mỗi nhánh này có 1 mục đích cụ thể và bị ràng buộc bởi các quy tắc nghiêm ngặt về việc branch off (rẽ nhánh/ phân nhánh) từ nhánh nào và phải được merge vào nhánh nào sau khi hoàn tất.

Feature branches (Topic branches)

• May branch off from: develop
• Must merge back into: develop
• Branch naming convention: feature/*, anything except master, develop, release-*, or hotfix-*

Feature branches được sử dụng để phát triển các tính năng (features) mới cho bản phát hành (release) sắp tới hoặc trong tương lai xa.

Feature branches thường chỉ tồn tại trong các repo của developer (local), chứ không tồn tại trong origin.

Tạo 1 feature branch

Khi bắt đầu làm việc trên một tính năng mới (a new feature), hãy tách nhánh từ develop branch.

    $ git checkout -b feature/implement-login develop
    Switched to a new branch "feature/implement-login"

Merge 1 tính năng (feautre) đã hoàn thiện vào nhánh develop

Các tính năng đã hoàn thiện có thể được merge vào nhánh develop để chắc chắn thêm chúng vào bản phát hành (release) sắp tới:

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff feature/implement-login
    Updating ea1b82a..05e9557
    (Summary of changes)
    $ git branch -d feature/implement-login
    Deleted branch feature/implement-login (was 05e9557).
    $ git push origin develop

Compare 2 git merge commands

Release branches

• May branch off from: develop
• Must merge back into: develop and master
• Branch naming convention: release-*

Khi tất cả các tính năng cần thiết và ổn định (stable) cho bản release được merge hoàn toàn vào nhánh develop, ta sẽ tách 1 nhánh release từ nhánh develop hiện tại. Release branche được sử dụng để chuẩn bị 1 bản release mới cho production (a new production release). Chúng cho phép fix các bugs nhỏ và chuẩn bị meta-data cho bản 1 release (version number, build dates,..). Bằng cách làm những việc này trên nhánh release ta có thể merge phát triển và merge các tính năng mới vào nhánh develop để chuẩn bị cho bản release tiếp theo.

Tạo 1 release branch

Release branch được tạo từ nhánh develop.

    $ git checkout -b release-1.0 develop
    Switched to a new branch "release-1.0"
    $ ./bump-version.sh 1.0
    Files modified successfully, version bumped to 1.0.
    $ git commit -a -m "Bumped version number to 1.0"
    [release-1.0 74d9424] Bumped version number to 1.0
    1 files changed, 1 insertions(+), 1 deletions(-)

Sau khi tạo một nhánh mới và chuyển sang nhánh đó, chúng ta cần đánh số phiên bản. Ở đây, bump-version.sh là một fictional (hư cấu) shell script thay đổi một số tệp trong bản sao đang hoạt động để phản ánh phiên bản mới. (Tất nhiên, đây có thể là một thay đổi thủ công — điểm mà một số tệp thay đổi.) Sau đó, số phiên bản bị thay đổi được commit.

Các bản sửa lỗi có thể được áp dụng trong nhánh này (thay vì trên nhánh develop). Việc thêm các tính năng mới (large new features) ở đây bị nghiêm cấm. Chúng phải được merge vào develop, và do đó, hãy đợi bản phát hành tiếp theo.

Finishing a release branch

Khi nhánh release đã hoàn thiện, ổn định và sẵn sàng để release, ta sẽ thực hiện các bước sau:

• 1. Merge nhánh release vào nhánh master;
• 2. Tạo 1 tag release từ nhánh master để có thể tham chiếu các version trong tương lai;
• 3. Merge nhánh release về nhánh develop, để các bản release trong tương lai cũng các bản vá lỗi của nhánh release (nếu có).

2 bước đầu tiên trong Git:

    $ git checkout master
    Switched to branch 'master'
    $ git merge --no-ff release-1.0
    Merge made by recursive.
    (Summary of changes)
    $ git tag -a 1.0

Bản release đã hoàn tất và được tagged để có thể tham chiếu trong tương lai.

Để giữ những thay đổi được thực hiện trong nhánh release, chúng ta cần phải merge những thay đổi đó vào nhánh develop:

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff release-1.0
    Merge made by recursive.
    (Summary of changes)

Bước này có thể dẫn đến merge conflict (thậm chí có thể do chúng ta đã thay đổi số phiên bản). Nếu vậy, hãy sửa nó và commit.

Bây giờ chúng ta thực sự đã hoàn tất và nhánh release có thể bị xóa, vì chúng ta không cần nó nữa:

    $ git branch -d release-1.0
    Deleted branch release-1.0 (was ff452fe).

Hotfix branches

• May branch off from: master
• Must merge back into: develop and master
• Branch naming convention: hotfix-*

Khi có một lỗi nghiêm trọng trong phiên bản sản xuất (production version) phải được giải quyết ngay lập tức, một nhánh hotfix có thể được tách ra khỏi thẻ tương ứng trên nhánh master đánh dấu phiên bản sản xuất (tag version).

Bản chất là công việc của các thành viên trong nhóm (trên nhánh develop) có thể tiếp tục, trong khi một người khác đang chuẩn bị 1 quick production fix.

Tạo 1 hotfix branch

Các nhánh hotfix được tạo từ nhánh master. Ví dụ: giả sử phiên bản 1.0 là phiên bản sản xuất hiện tại đang chạy trực tiếp và gây ra sự cố do một lỗi nghiêm trọng. Nhưng những thay đổi trên nhánh develop vẫn chưa ổn định. Do đó, chúng ta có thể phân nhánh một nhánh hotfix và bắt đầu khắc phục sự cố:

    $ git checkout -b hotfix-1.0.1 master
    Switched to a new branch "hotfix-1.0.1"
    $ ./bump-version.sh 1.0.1
    Files modified successfully, version bumped to 1.0.1.
    $ git commit -a -m "Bumped version number to 1.0.1"
    [hotfix-1.0.1 41e61bb] Bumped version number to 1.0.1
    1 files changed, 1 insertions(+), 1 deletions(-)

Đừng quên tăng số phiên bản sau khi phân nhánh!

Sau đó, fix bug and commit các thay đổi:

    $ git commit -m "Fixed severe production problem"
    [hotfix-1.0.1 abbe5d6] Fixed severe production problem
    5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch

Khi hoàn tất, bản sửa lỗi cần được merge trở lại vào nhánh master và cũng cần được merge trở lại vào nhánh develop, để bảo đảm rằng bản sửa lỗi cũng được bao gồm trong bản phát hành tiếp theo. Điều này hoàn toàn tương tự như cách kết thúc các nhánh release.

Đầu tiên, update master and tag the release.

    $ git checkout master
    Switched to branch 'master'
    $ git merge --no-ff hotfix-1.0.1
    Merge made by recursive.
    (Summary of changes)
    $ git tag -a 1.0.1

Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.

Tiếp theo, merge nhánh hotfix vào nhánh develop:

    $ git checkout develop
    Switched to branch 'develop'
    $ git merge --no-ff hotfix-1.0.1
    Merge made by recursive.
    (Summary of changes)

Một ngoại lệ đối với quy tắc ở đây là, khi một nhánh release hiện đang tồn tại, các thay đổi hotfix cần được merge vào nhánh release đó, thay vì nhánh develop. Việc merge lại bản sửa lỗi vào nhánh release cuối cùng sẽ dẫn đến việc bản sửa lỗi cũng được merge vào phát triển, khi nhánh release kết thúc. (Nếu công việc trong nhánh develop yêu cầu bản sửa lỗi này ngay lập tức và không thể đợi nhánh release hoàn thành, bạn cũng có thể merge bản sửa lỗi vào nhánh develop ngay bây giờ một cách an toàn.)

Cuối cùng, xoá nhánh hotfix đã hoàn thành:

    $ git branch -d hotfix-1.0.1
    Deleted branch hotfix-1.0.1 (was abbe5d6).