Đâ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.
Đang xem: Git flow là gì
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 =))) ).
Xem thêm: Cách Chơi Camille Mùa 11 – Cách Chơi Camile Tốc Chiến Mùa 2
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.
Xem thêm: To Take Turns Là Gì, Nghĩa Của Từ To Take Turns, Cụm Diễn Đạt Tiếng Anh Thông Dụng Với
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. 
