Bạn đã hiểu rõ về git flow chưa?
Git
54
gitflow
2
White

ShinaBR2 viết ngày 18/07/2017

Đây là một vấn đề kinh điển, và có rất nhiều bài viết về nó, tuy nhiên đa phần là dịch từ bản gốc ra và sao chép lại một vài câu lệnh, và câu hỏi tôi đặt ra là trong thực tế, git flow diễn ra như thế nào?

Tôi đã từng thắc mắc câu hỏi này dù đọc đi đọc lại những bài viết về git flow rất nhiều lần. Và giờ tôi sẽ đưa ra một ví dụ cụ thể để bạn có thể hiểu và dễ dàng nhớ được. Ứng dụng git flow vào một dự án thực tế là điều rất cần thiết và giúp chúng ta quản lý code, fix bug cũng dễ dàng hơn rất nhiều. Tôi sẽ trình bày lại một cách dễ hiểu và thực tế nhất.

Tôi xin lấy ví dụ với một dự án xây dựng một trang web xem tin tức chẳng hạn. Sau khi phân tích yêu cầu, thiết kế giao diện... thì cuối cùng tới bước code, việc đầu tiên một anh developer làm đó là lên bitbucket tạo sẵn một repository rỗng. Sau đó tạo một thư mục dưới local, chỉnh host các thứ, tạo cấu trúc thư mục theo framework, cài các thư viện... mọi thứ xong xuôi hết rồi chúng ta kết nối với repository trên bitbucket bằng git clone. Sau đó tiếp tục code một dòng hello world, rồi commit và push lên repository trên bitbucket với commit message là "First commit".
Nghe quen phải không =)) rồi tiếp. Khi commit đầu tiên được push lên, thì reposity của chúng ta lúc đó đã có một branch là master. Rồi tới đây, sếp mới bảo đầu tiên chúng ta phải làm công việc đầu tiên là làm giao diện. Vâng, và sau khi câu nói thần thánh ấy được cất lên, sếp tạo một branch mới có tên là develop. Vào thời điểm này, cả hai nhánh đều chưa có gì ngoài commit chứa câu hello world ban nãy. Hoặc bạn không thích có thể echo ra file readme.md cho đúng chuẩn cũng được =))
Tiếp theo, các anh em dev chúng ta miệt mài code, miệt mài fix bug, miệt mài căm thù bọn QC (mọi hoạt động lúc này diễn ra trên nhánh develop) cho tới một ngày đẹp trời, có hai trường hợp xảy ra:

  • Giao diện chạy đã ngon lành, "có vẻ như" không có bug và có thể release ngay. Tùy vào tính cẩn thận của sếp lúc này, nếu cẩn thận, sếp sẽ làm một động thái là tạo một branch mới tên là release 0.1 sau đó checkout code từ nhánh develop sang nhánh release 0.1 này. Tiếp tục, sẽ kiểm tra lại lần cuối xem thử có thiếu sót gì không, logo, icon, metadata các kiểu sẵn sàng để production hay chưa. Phải luôn nhớ, trên nhánh release chỉ fix bug, không được code thêm tính năng. Nếu có bug, thì sếp sẽ hú một vài thành phần dev vào fix. Thì những ai được lệnh fix sẽ chuyển sang nhánh release 0.1, hì hục fix bug cho tới khi mọi thứ ổn thỏa, những thành viên còn lại tiếp tục làm task mới hoặc đi ăn sáng uống cà phê. Thao tác cuối cùng là sếp merge nhánh release 0.1 này vào master, sau đó merge tiếp lại vào nhánh develop (đừng quên chuyện này nha, không thì sau này code tiếp trên nhánh develop sẽ có bug). Tuy nhiên trên đời không phải ông sếp nào cũng như ông sếp nào, gặp ông sếp ẩu ẩu, lười không chịu tách ra một branch release 0.1 như ở trên, ổng sẽ merge luôn vào master để release, lạy thánh =)) nhưng không sao, nếu có bug, QC sẽ phát hiện ra ngay thôi (trường hợp này tôi mạo phép tin tưởng là QC phát hiện ra bug =))) ). Và lúc này đây, ông sếp ấy phải làm một cái thao tác để phần nào sữa chữa cái lỗi lầm kia đó là tạo một branch mới tên là hotfix 0.1.1 từ nhánh master rồi lại hú anh em vào đấy fix. Tương tự, anh em đang vi vu bên nhánh khác lại phải chuyển sang nhánh hotfix, fix bug bên nhánh hotfix này cho tới khi đâu lại vào đấy, xong xuôi hết rồi sếp phải merge code từ nhánh hotfix này sang master, sau đó phải merge tiếp code từ nhánh hotfix trở lại nhánh develop tương tự như nhánh release ở trên vậy. Tại sao phải như vậy? Bởi vì code trên nhánh master phải là code release được ngay và không có bug gì hết, phải luôn nhớ như vậy. Và 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 đó. Tới đây, ông sếp của chúng ta đã có thể phè phỡn xóa đi hai nhánh release và hotfix. Xong version 0.1 của project, hệ thống đã có giao diện hoàn chỉnh, sếp ra quán cà phê phì phèo điếu thuốc còn anh em dev chúng ta chuyển lại về nhánh develop làm tiếp những task tiếp theo, đời dev là thế =))
  • Trường hợp đang làm giao diện chưa xong mà bị có task mới ập đến, yêu cầu chúng ta phải cho ra lò tính năng đọc tin tức ngay. Động thái lúc này của sếp phải là tạo một branch mới tên là feature-loadnews. Ồ, một bộ phận làm giao diện thì phải làm cho xong thì trụ lại ở nhánh develop, một vài thanh niên trâu bò khác phải chuyển qua làm tính năng này phải chuyển qua nhánh feature-loadnews. Lại tiếp tục guồng quay vô tận là code, cho tới khi tính năng này xong. Khi code xong, anh em chúng ta hú sếp để sếp merge code từ nhánh feature-loadnews này vào develop, deploy code trên nhánh develop và cho bọn QC vào test. Merge code thì luôn luôn có xác suất bị conflict với nhóm đang còn làm giao diện trên kia kìa, thì resolve conflict hết trước khi giao cho QC nhé. Có thể hiểu nôm na, để cho QC test, luôn luôn deploy code từ nhánh develop.

Trong quá trình code, trong lần đầu tiên tạo project, có thể không cần phải tạo nhánh release-layout để code giao diện sau đó merge vào nhánh develop, mà có thể làm thẳng trên develop luôn. Từ những tính năng sau trở đi, hễ có tính năng mới là phải tạo nhánh release mới, mỗi nhánh release tương ứng với một tính năng, và anh em dev ai code tính năng nào thì chuyển qua nhánh tương ứng. Ví dụ khi mới xong giao diện, một nhóm còn đang làm tính năng loadnews ở trên thì đẻ thêm chuyện là làm trang admin quản lý tin tức. Dĩ nhiên, cùng một thời điểm có thể phát sinh nhiều tính năng, và việc phải tạo nhiều nhánh release là hết sức bình thường, tuy nhiên những tính năng đó không ràng buộc lẫn nhau. Ví dụ không thể làm tính năng hiển thị tin tức theo danh mục trong khi tính năng lấy tin tức về còn chưa làm xong được phải không nào.
Điểm lại, anh em code thì chủ yếu làm việc trên những nhánh gọi là feature, và ta nên đặt tên cho nhánh đó dễ hiểu chút, ví dụ feature-layout, feature-loadnews, feature-login... nhìn vào là biết nhánh đó đang làm gì. Sếp thì công việc chủ yếu ở nhánh develop, merge code từ các nhánh release vào develop để chuyển cho QC test. Khi ok hết rồi, có khả năng production được rồi thì merge từ develop sang master để release.

Trên đây là một ví dụ rất thực tế để áp dụng git flow vào dự án. Hi vọng mọi người đọc xong là có thể hiểu ngay và chẳng cần thiết nhìn lại vào bức ảnh kinh điển về git flow để nhớ là cụ thể nó như thế nào. Bức ảnh thần thánh ấy đây. gitflow

Cảm ơn mọi người đã đọc bài viết, hi vọng được nhiều ý kiến đóng góp.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

ShinaBR2

10 bài viết.
91 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
36 10
Vào một ngày đẹp trời, khi bạn nhận được yêu cầu phải thiết kế database cho một hệ thống, câu hỏi đầu tiên được đặt ra, quy trình làm ra nó sẽ cụ t...
ShinaBR2 viết 12 tháng trước
36 10
White
32 10
Bàn về code thối Hãy tự đặt câu hỏi cho bạn, khi bắt đầu lập trình, bạn nghĩ tới điều gì? Đi phỏng vấn Điều đầu tiên tôi muốn nói về những câu hỏ...
ShinaBR2 viết 7 tháng trước
32 10
White
27 17
Single Page Applications, hay mình thường gọi là Single Page App SPA giờ đã trở nên quá đỗi quen thuộc và là một xu hướng của web. Vậy bạn đã thực ...
ShinaBR2 viết 11 tháng trước
27 17
Bài viết liên quan
White
49 8
Tôi xin tổng hợp các cách dùng git stash tôi hay sử dụng Lưu lại thay đổi Git stash được sử dụng khi muốn lưu lại các thay đổi chưa commit, thườ...
BB viết 3 năm trước
49 8
White
13 2
Xin chào các bạn. Chắc hẳn mỗi chúng ta đều đã từng phát triển app sử dụng API của bên thứ 3, và chắc mọi người đều biết là hầu hết các API service...
Hải Nguyễn viết hơn 1 năm trước
13 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
91 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!