Giới thiệu

Git flow là một chiến lược quản lý branch trong Git, được Vincent Driessen giới thiệu vào năm 2010. Mục đích của Gitflow là tổ chức quá trình phát triển và phát hành phần mềm bằng cách quy định vai trò của từng loại branch và cách các branch tương tác với nhau.

Thay vì tất cả lập trình viên cùng làm việc trực tiếp trên một branch, Gitdlow chia quá trình phát triển thành nhiều branch có mục đích khác nhau, chẳng hạn như main, develop, feature, realease và  hotfix.

Gitflow đặc biệt phù hợp với những dự án có chu kỳ phát hành tương đối rõ ràng, trong đó team cần phân biệt giữa code đang phát triển, code chuẩn bị release và code đang chạy trên production.

Gitflow không phải là một tính năng hay một phiên bản khác của Git. Nó là một workflow được xây dựng dựa trên các chức năng branch và merge có sẵn của Git. Điều quan trọng của Gitflow là quy định khi nào sử dụng branch nào, branch đó dùng để làm gì và chúng được merge với nhau như thế nào.

Trong bài viết này, chúng ta sẽ tìm hiểu từng loại branch trong Gitflow, cách chúng tương tác với nhau và quy trình từ khi bắt đầu phát triển một feature cho đến khi đưa phiên bản mới lên production.

Tổng quan

Gitflow là một workflow được xây dựng dựa trên Git, quy định cách tổ chức và sử dụng các branch trong quá trình phát triển phần mềm. Nó xác định vai trò của từng loại branch, cách tạo branch và cách các branch được merge với nhau.

Mô tả tổng quan về Gitflow workflow:

Quy trình làm việc của Gitflow

• Main branch: Thường được gọi là “master” với thuật ngữ cũ. Đây là branch chứa mã nguồn đã sẵn sàng để phát hành và triển khai lên môi trường production.

Trong quy trình Git, nhánh chính được tạo lúc ban đầu dự án và được duy trì xuyên suốt trong quá trình phát triển. Mỗi commit trên nhánh main tương ứng với 1 phiên bản chính thức của dự án. Mỗi khi một phiên bản hoàn chỉnh được phát hành, các thay đổi tương ứng sẽ được merge vào main và có thể được đánh dấu bằng một version tag.

• Develop branch: Được khởi tạo từ main branch khi bắt đầu quá trình phát triển, được duy trì trong suốt quá trình phát triển. Đây là branch dùng để tích hợp các feature đã hoàn thành và tiếp tục phát triển phiên bản kế tiếp của phần mềm.

Trong suốt quá trình phát triển, các feature branch sẽ được tạo từ develop và sau khi hoàn thành sẽ được merge trở lại develop.

Các nhánh hỗ trợ

Khi phát triển phần mềm với Gitflow có ba loại nhánh hỗ trợ với mục đích khác nhau: feature, realease, hotfix.

• Feature branch:Là loại branch được sử dụng để phát triển một feature mới. Khi bắt đầu phát triển một feature, một branch mới sẽ được tạo từ develop, thường có dạng feature/<tên-deature>.

Developer sẽ thực hiện việc viết và kiểm thử code trên branch này. Sau khi feature hoàn thành, branch có thể được tạo Pull Request/Merge Request để review và sau đó merge vào develop.

• Release branch: Được sử dụng khi chuẩn bị một phiên bản mới để phát hành. Trước khi phát hành, một release branch sẽ được tạo từ develop.

Sau khi được tạo, phạm vi tính năng của phiên bản này về cơ bản được cố định. Team chủ yếu tập trung vào việc kiểm thử, sửa lỗi và hoàn thiện các vấn đề liên quan đến việc phát hành.

Khi phiên bản đã sẵn sàng, release branch sẽ được merge vào main để phát hành, đồng thời được merge trở lại develop để đảm bảo các thay đổi trong quá trình chuẩn bị release được đồng bộ với branch phát triển.

• Hotfix branch:Được sử dụng để sửa nhanh các lỗi nghiêm trọng xuất hiện trên phiên bản đang chạy ở môi trường production.

hotfix branch được tạo từ main vì main đang chứa phiên bản hiện tại được triển khai trên production.

Sau khi lỗi được sửa và kiểm thử, hotfix branch sẽ được merge vào main để cập nhật phiên bản production. Đồng thời, thay đổi cũng cần được merge trở lại develop để đảm bảo bản sửa lỗi được duy trì trong các phiên bản tiếp theo.

Lưu ý khi sử dụng Git

Sử dụng Merge Request

Trong các team phát triển phần mềm, việc merge code trực tiếp vào các branch quan trọng như develop hoặc main thường bị hạn chế. Thay vào đó, developer tạo Merge Request (MR) để code được review trước khi merge.

Merge Request mang lại một số lợi ích:

• Code review: Người review có thể kiểm tra mã nguồn trước khi merge, phát hiện lỗi hoặc những vấn đề trong cách triển khai. Điều này đặc biệt quan trọng khi nhiều developer cùng làm việc trên một dự án.
• Trao đổi trong quá trình review: Reviewer có thể comment trực tiếp vào những đoạn code cần thay đổi. Developer có thể phản hồi và chỉnh sửa ngay trên Merge Request, giúp quá trình trao đổi rõ ràng và dễ theo dõi hơn.
• Lưu lại quá trình review: Merge Request lưu lại các commit, thay đổi trong code, comment của reviewer và quá trình xử lý các yêu cầu thay đổi. Khi cần kiểm tra lại một feature hoặc tìm hiểu lý do một thay đổi được thực hiện, team có thể xem lại Merge Request liên quan thay vì chỉ xem từng commit riêng lẻ.

Ngoài ra, các thành viên trong team cũng có thể xem lại những Merge Request trước đó để học hỏi cách giải quyết vấn đề và cách viết code của những thành viên khác.

Trong nhiều team, các branch quan trọng như develop, release và main thường được bảo vệ và hạn chế việc push hoặc merge trực tiếp. Các thay đổi vào những branch này thường được thực hiện thông qua Merge Request.

Conflict code

Conflict là vấn đề thường gặp khi nhiều developer cùng làm việc trên một codebase. Conflict xảy ra khi Git không thể tự động xác định cách kết hợp các thay đổi từ những branch khác nhau.

Một số cách giúp hạn chế conflict:

• Chia code thành các module có trách nhiệm rõ ràng, hạn chế để quá nhiều logic trong một file.
• Hạn chế để nhiều developer cùng chỉnh sửa một khu vực của code nếu không cần thiết.
• Thường xuyên đồng bộ branch đang phát triển với branch đích để cập nhật những thay đổi mới nhất.
• Trước khi tạo Merge Request, kiểm tra xem branch hiện tại có đang bị conflict với branch đích hay không và xử lý conflict nếu cần.
• Giữ các commit và thay đổi tương đối nhỏ, tập trung vào một feature hoặc một nhiệm vụ cụ thể.

Nguồn tham khảo:

1. Cơ bản về Gitflow Workflow
2. What is Git Flow

Bài viết khác

Waterfall

Waterfall là gì? Waterfall hay còn gọi là mô hình thác nước, là một mô hình phát triển phần mềm theo hướng tuần tự. Có nghĩa là một dự án sẽ được chia thành nhiều giai đoạn và team sẽ thực hiện lần lượt từng giai đoạn, thường phải hoàn thành bước trước rồi mới […]

Đọc thêm

WaterFall

1. Waterfall là gì và cách thức hoạt động? Waterfall (hay còn gọi là mô hình thác nước) là một trong những phương pháp quản lý và phát triển phần mềm mang tính cổ điển, tuần tự theo đúng nghĩa đen. Giống như một dòng thác nước chảy từ trên đỉnh núi xuống dưới, quy […]

Đọc thêm

AGILE

1. Agile là gì? Agile (phương pháp phát triển phần mềm linh hoạt) không phải là một công cụ hay một quy trình kỹ thuật cụ thể nào cả, mà nó là một tư duy (mindset) và triết lý làm việc. Thay vì lập ra một kế hoạch khổng lồ từ đầu, làm một mạch […]

Đọc thêm

GIT

1. Git là gì? -Git là hệ thống quản lý phiên bản (Version Control System – VCS) được sử dụng cực kỳ phổ biến trong phát triển phần mềm hiện đại. Git giúp developer theo dõi, quản lý và lưu lại lịch sử thay đổi của source code trong suốt quá trình phát triển dự […]

Đọc thêm

Agile

Agile là gì? Agile là cách tư duy và tiếp cận trong việc phát triễn sản phẩm, tập trung vào việc tạo ra giá trị sớm chi nhỏ công việc nhận phản hồi thường xuyên từ khách hàng và liên tực thích nghi với những thay đổi trong quá trình phát triển.   Các đặc […]

Đọc thêm

git

git là gì ? Git là một hệ thống quản lý phiên bản (Version Control System – VCS) được sử dụng phổ biến trong phát triển phần mềm. Git giúp developer theo dõi, quản lý và lưu lại lịch sử thay đổi của source code trong quá trình phát triển dự án. Thay vì chỉ […]

Đọc thêm