Hiểu Git Flow: Quy trình làm việc có cấu trúc cho các nhóm phát triển phần mềm

Nấu một bữa ăn bao gồm nhiều giai đoạn, chẳng hạn như lập kế hoạch, chuẩn bị, nấu nướng và bày biện. Nếu bạn phải nấu nhiều món ăn cùng một lúc, nhiều người có thể chịu trách nhiệm cho các phần khác nhau của bữa ăn. Bằng cách chia quy trình nấu ăn thành các bước nhỏ hơn, dễ quản lý hơn và giao nhiệm vụ cho những người khác nhau, bạn có thể đảm bảo rằng bữa ăn được chuẩn bị đúng giờ và hài lòng.

Các nguyên tắc của Git Flow giống như quy trình nấu một bữa ăn, vì cả hai đều đòi hỏi phải chia nhỏ một nhiệm vụ phức tạp thành các giai đoạn nhỏ hơn, dễ quản lý hơn và giao trách nhiệm cho các cá nhân khác nhau. Git Flow thực hiện điều này bằng cách chia quy trình phát triển phần mềm thành các giai đoạn riêng biệt như phát triển tính năng, thử nghiệm và phát hành, với các thành viên trong nhóm, được phân bổ các nhiệm vụ cụ thể. Phương pháp này đảm bảo rằng quy trình phát triển phần mềm được sắp xếp hợp lý và mang lại một sản phẩm hàng đầu.

Bài viết bạn đang đọc là phiên bản được Google dịch của bài viết gốc bằng tiếng Anh có sẵn tại https://vulehuan.com/en/blog/2023/03/understanding-git-flow-a-structured-workflow-for-software-development-teams-44.html. Huân khuyến khích bạn tham khảo bài viết gốc để hiểu chính xác và toàn diện hơn về chủ đề này.

Git Flow là gì?

Các nhà phát triển phần mềm thường xuyên sử dụng Git, một hệ thống kiểm soát phiên bản, để quản lý cơ sở mã của họ. Bạn có thể tìm thêm thông tin về Git tại https://vulehuan.com/vi/blog/2023/03/hieu-ve-git-va-cac-he-thong-kiem-soat-phien-ban-khac-43.html.

Git Flow được tạo bởi Vincent Driessen vào năm 2010 dưới dạng mô hình phân nhánh cho Git. Driessen đã viết một bài đăng trên blog (https://nvie.com/posts/a-successful-git-branching-model/) giải thích chiến lược phân nhánh của mình, mà ông gọi là "Mô hình phân nhánh Git thành công" và chiến lược này đã trở nên phổ biến đối với các nhà phát triển. Kể từ đó, mô hình Git Flow đã được nhiều nhóm phát triển phần mềm áp dụng và trở thành một phương pháp được sử dụng rộng rãi để quản lý quy trình phát triển phần mềm.

Git Flow là một mô hình được sử dụng để phân nhánh trong Git, đây là hệ thống kiểm soát phiên bản được sử dụng rộng rãi trong phát triển phần mềm. Mục tiêu chính của nó là hỗ trợ các nhóm quản lý và điều phối quy trình phát triển phần mềm của họ bằng cách chia quy trình thành nhiều giai đoạn riêng biệt, với mỗi giai đoạn có nhánh riêng. Điều này cho phép các thành viên trong nhóm làm việc đồng thời trên các tính năng và thay đổi khác nhau mà không làm gián đoạn công việc của nhau.

Mô hình Git Flow thường bao gồm hai nhánh chính, đó là nhánh "master", đại diện cho mã ổn định, sẵn sàng đưa lên production chạy chính thức; và nhánh "develop", đóng vai trò là nền tảng cho sự phát triển liên tục. Các nhánh bổ sung như nhánh feature, nhánh release và nhánh hotfix được thiết lập khi cần thiết để hỗ trợ các tác vụ cụ thể như thêm tính năng mới, thử nghiệm và chuẩn bị phát hành hoặc giải quyết các sự cố nghiêm trọng. Bằng cách tuân theo mô hình phân nhánh Git Flow, các nhóm có thể duy trì quy trình làm việc được tổ chức tốt, tránh xung đột và đảm bảo chất lượng mã cũng như độ ổn định ở mức cao.

Git Flow là một mô hình phân nhánh có giá trị cho các nhóm phát triển phần mềm, cung cấp quy trình làm việc có cấu trúc và tổ chức. Bằng cách sử dụng Git Flow, các nhóm có thể vượt qua những thách thức phổ biến trong quá trình phát triển phần mềm như quản lý cơ sở mã, tránh xung đột cũng như duy trì chất lượng và độ ổn định của mã. Trong blog này, chúng ta sẽ đi sâu hơn vào các lợi ích của Git Flow và cung cấp các ví dụ về cách nó có thể giúp các nhóm khắc phục lỗi và xử lý nhiều nhà phát triển làm việc trên cùng một dự án.

Làm thế nào Git Flow có thể được sử dụng cho một nhánh tính năng (feature)?

• Tạo nhánh tính năng: Trong Git Flow, một nhánh tính năng được thiết lập khi một tính năng mới đang được phát triển. Để bắt đầu một nhánh tính năng, bạn sẽ sử dụng lệnh git flow feature start feature-name trong terminal của mình. Điều này tạo ra một nhánh mới có tên “feature/feature-name” dựa trên nhánh "develop".
• Phát triển tính năng: Sau khi nhánh tính năng được thiết lập, nhà phát triển có thể làm việc với tính năng của họ mà không ảnh hưởng đến nhánh "develop". Họ có thể add và commit các thay đổi của mình đối với nhánh “feature/feature-name” khi họ làm việc trên đó.
• Hợp nhất nhánh tính năng: Khi hoàn thành tính năng này, nó có thể được hợp nhất vào nhánh “develop” bằng cách sử dụng lệnh git flow feature finish feature-name trong terminal của bạn. Thao tác này sẽ hợp nhất các thay đổi trong nhánh “feature/feature-name” trở lại nhánh “develop”, xóa nhánh “feature/feature-name” và chuyển bạn trở lại nhánh “develop”.
• Đánh giá thay đổi: Sau khi hợp nhất nhánh tính năng, các thay đổi phải được xem xét và kiểm tra kỹ lưỡng trước khi hợp nhất nhánh “develop” vào nhánh “master” để phát hành. Điều này đảm bảo rằng tính năng mới ổn định và không gây ra bất kỳ sự cố nào.

Tóm lại, mô hình phân nhánh Git Flow cho phép các nhóm quản lý quy trình phát triển tính năng của họ một cách có tổ chức và có cấu trúc. Nó cũng cho phép nhiều nhà phát triển làm việc đồng thời trên các tính năng khác nhau mà không gây trở ngại cho công việc của nhau.

Bạn nên thực hiện thao tác "git pull" trên nhánh "develop" trước khi kết thúc nhánh tính năng, vì điều này đảm bảo rằng bạn có những thay đổi cập nhật nhất từ các thành viên khác trong nhóm. Sau khi kết thúc nhánh tính năng với git flow feature finish feature-name, bạn sẽ tự động được chuyển trở lại nhánh "develop". Tại thời điểm này, bạn nên thực hiện git push để push các thay đổi của mình vào kho lưu trữ từ xa để các thành viên khác trong nhóm có thể truy cập các thay đổi mà bạn đã thực hiện.

Để minh họa, giả sử bạn muốn thêm chức năng đăng nhập vào phần mềm của mình bằng Git Flow:

• Đầu tiên, bạn sẽ chạy lệnh git checkout develop && git pull && git flow feature start login trong terminal của mình để tạo một nhánh mới gọi là "feature/login" dựa trên nhánh "develop".
• Sau đó, các nhà phát triển có thể làm việc trên nhánh "feature/login" mà không ảnh hưởng đến nhánh "develop" bằng cách thực hiện các thay đổi của họ và commit chúng với nhánh “feature/login”. Ví dụ: họ có thể thêm biểu mẫu đăng nhập và logic vào nhánh.
• Sau khi tính năng này hoàn tất, tính năng này sẽ được xem xét và kiểm tra để đảm bảo tính năng này đáp ứng các tiêu chuẩn chất lượng và chức năng mong muốn. Điều này có thể được thực hiện bằng cách tạo một "Pull Request" để hợp nhất nhánh "feature/login" vào nhánh "develop" để xem xét và kiểm tra mã.
• Sau khi xem xét và thử nghiệm thành công, các thay đổi có thể được hợp nhất trở lại nhánh "develop" bằng cách sử dụng lệnh git checkout develop && git pull && git flow feature finish login && git push origin develop. Điều này sẽ hợp nhất các thay đổi trong nhánh "feature/login" thành "develop", xóa nhánh "feature/login" và chuyển bạn trở lại nhánh "develop".
• Cuối cùng, khi tất cả các tính năng đã được phát triển và hợp nhất vào nhánh "develop", nó có thể được hợp nhất vào nhánh "master" để phát hành và triển khai. Bạn có thể tìm hiểu thêm về cách Git Flow có thể được sử dụng cho nhánh phát hành (release) trong bài viết này.

Làm thế nào Git Flow có thể được sử dụng cho một nhánh phát hành (release)?

Các nhóm phát triển phần mềm cũng có thể sử dụng Git Flow cho nhánh phát hành. Nhánh phát hành được tạo khi nhóm sẵn sàng chuẩn bị cho phiên bản mới của phần mềm được đưa lên production chạy chính thức. Dưới đây là một số ví dụ về cách Git Flow có thể được sử dụng cho nhánh phát hành:

• Để tạo nhánh phát hành trong Git Flow, bạn sẽ chạy lệnh git flow release start release-name trong terminal của mình. Điều này tạo ra một nhánh mới gọi là "release/release-name" dựa trên nhánh "develop".
• Khi nhánh phát hành được tạo, các nhà phát triển có thể làm việc để chuẩn bị phát hành mà không ảnh hưởng đến nhánh "develop". Họ có thể thực hiện các thay đổi và sửa lỗi cuối cùng để đảm bảo bản phát hành ổn định và cam kết các thay đổi của họ đối với nhánh phát hành khi họ làm việc trên đó.
• Sau khi chuẩn bị phát hành, nó phải được kiểm tra kỹ lưỡng để đảm bảo nó đáp ứng các tiêu chuẩn chất lượng và chức năng mong muốn. Điều này có thể được thực hiện bằng cách tạo một "Pull Request" để hợp nhất nhánh "release/release-name" vào nhánh "master" để thử nghiệm.
• Sau khi bản phát hành được xem xét và kiểm tra, nó có thể được hợp nhất trở lại vào cả hai nhánh "develop" và "master" bằng cách chạy lệnh git flow release finish release-name trong terminal của bạn. Điều này sẽ hợp nhất các thay đổi trong nhánh "release/release-name" thành cả "develop" và "master", xóa nhánh "release/release-name" và chuyển bạn trở lại nhánh "develop".

Bằng cách tuân theo mô hình phân nhánh Git Flow cho các nhánh phát hành, các nhóm có thể duy trì quy trình làm việc có cấu trúc và tổ chức, đảm bảo chất lượng mã và độ ổn định cao, đồng thời tránh xung đột trong quá trình phát hành.

Quá trình sử dụng Git Flow để hoàn thành một nhánh phát hành bao gồm pull các thay đổi từ các nhánh "develop" và "master" trước khi hoàn thiện nhánh phát hành với git flow release finish release-name. Sau khi hoàn thiện nhánh phát hành, các thay đổi phải được push sang cả nhánh "develop" và "master" bằng cách sử dụng git push và tag được tạo tự động cho phiên bản phát hành. Điều quan trọng là push tag vào kho lưu trữ từ xa để những người khác có thể dễ dàng xác định phiên bản mã nào đang được sử dụng trên production. Để liệt kê tất cả các tag trong kho lưu trữ Git, hãy sử dụng "git tag" và để chuyển sang một tag cụ thể, hãy sử dụng git checkout tag-name. Sử dụng git push --tags hoặc git push origin tag-name để push các tag vào kho lưu trữ từ xa.

Ví dụ: nếu bạn đang chuẩn bị phát hành phiên bản 1.0 của phần mềm, bạn có thể:

• Tạo nhánh phát hành: Để tạo nhánh phát hành, bạn sẽ chạy lệnh git checkout develop && git pull && git flow release start 1.0 trong terminal của mình. Thao tác này tạo ra một nhánh mới gọi là "release/1.0" dựa trên nhánh "develop".
• Chuẩn bị phát hành: Sau khi nhánh phát hành được tạo, các nhà phát triển có thể chuẩn bị phát hành mà không ảnh hưởng đến nhánh "develop". Họ có thể thực hiện các thay đổi và sửa lỗi cuối cùng để đảm bảo bản phát hành ổn định. Họ có thể chuyển giao các thay đổi của mình cho nhánh phát hành khi họ làm việc trên đó. Ví dụ: họ có thể cập nhật số phiên bản trong phần mềm, sửa bất kỳ lỗi nghiêm trọng nào và đảm bảo rằng tất cả các bài kiểm tra đều vượt qua.
• Kiểm tra bản phát hành: Sau khi bản phát hành được chuẩn bị, nó cần được kiểm tra kỹ lưỡng để đảm bảo nó đáp ứng các tiêu chuẩn chất lượng và chức năng mong muốn. Điều này có thể được thực hiện bằng cách tạo một "Pull Request" để hợp nhất nhánh "release/1.0" vào nhánh "master" để thử nghiệm. Ví dụ: bạn có thể có một nhóm người kiểm tra đánh giá bản phát hành để đảm bảo rằng tất cả các tính năng hoạt động như mong đợi và không có vấn đề lớn nào.
• Hoàn thiện bản phát hành: Sau khi bản phát hành được xem xét và kiểm tra, nó có thể được hợp nhất trở lại vào cả hai nhánh "develop" và "master" bằng cách chạy lệnh git checkout develop && git pull && git checkout master && git pull && git flow release finish 1.0 trong terminal của bạn. Thao tác này sẽ hợp nhất các thay đổi trong nhánh "release/1.0" trở lại thành cả “develop” và “master”, xóa nhánh "release/1.0" và chuyển bạn trở lại nhánh "develop".
• Để push các nhánh "develop" và "master" cùng với tag mới "1.0", hãy thực hiện các lệnh sau: git push origin develop && git push origin master && git push origin 1.0

Các quy tắc và quy ước đặt tên phát hành phổ biến

• Phiên bản theo ngữ nghĩa: Quy ước này liên quan đến việc sử dụng số phiên bản gồm ba phần (ví dụ: 1.2.3) để chỉ ra các bản phát hành chính, phụ và bản vá tương ứng. Để biết thêm thông tin, hãy truy cập: https://semver.org/
• Phiên bản lịch: Quy ước này liên quan đến việc sử dụng ngày phát hành làm số phiên bản (ví dụ: 2022.03.01). Để biết thêm thông tin, hãy truy cập: https://calver.org/
• Tên động vật: Quy ước này liên quan đến việc sử dụng tên động vật cho các phiên bản phát hành, chẳng hạn như việc sử dụng tên động vật của Ubuntu và việc Google sử dụng tên động vật cho các bản phát hành Android. Để biết thêm thông tin về quy ước đặt tên của Ubuntu, hãy truy cập https://wiki.ubuntu.com/DevelopmentCodeNames.
• Bản phát hành được đặt tên: Quy ước này liên quan đến việc đặt cho các bản phát hành những cái tên độc đáo và dễ nhớ, chẳng hạn như việc Apple sử dụng tên mèo lớn cho các bản phát hành OS X của họ (ví dụ: Sư tử núi, Sư tử, Báo hoa mai, v.v.).
• Đánh số thứ tự: Quy ước này liên quan đến việc sử dụng hệ thống đánh số thứ tự cho các bản phát hành, chẳng hạn như việc Microsoft sử dụng số phiên bản cho các bản phát hành Windows (ví dụ: Windows 10, Windows 11).

Làm thế nào Git Flow có thể được sử dụng cho một nhánh hotfix?

Nếu bạn có một ứng dụng phần mềm có lỗi nghiêm trọng cần sửa ngay lập tức, hotfix có thể được sử dụng để giải quyết vấn đề kịp thời mà không làm gián đoạn quá trình phát triển thông thường. Ví dụ: nếu có lỗ hổng bảo mật trong ứng dụng web, việc tạo nhánh hotfix từ nhánh "master" bằng cách sử dụng luồng hotfix có thể khắc phục sự cố và các thay đổi có thể được hợp nhất trở lại vào cả nhánh "master" và "develop". Tương tự, nếu một ứng dụng dành cho thiết bị di động có một lỗi nghiêm trọng đang ảnh hưởng đến trải nghiệm người dùng, hotfix có thể được sử dụng để khắc phục sự cố và triển khai các thay đổi lên production mà không cần đợi chu kỳ phát hành thông thường.

Trong quá trình phát triển phần mềm, Git Flow cũng có thể được sử dụng cho một nhánh hotfix, khi cần có một bản sửa lỗi khẩn cấp cho một sự cố trên production. Để tạo một nhánh hotfix, lệnh git flow hotfix start hotfix-name được sử dụng trong terminal, tạo một nhánh mới có tên hotfix/hotfix-name dựa trên nhánh "master". Các nhà phát triển có thể thực hiện các thay đổi cần thiết để khắc phục sự cố và commit các thay đổi của họ với nhánh hotfix. Hotfix cần được kiểm tra kỹ lưỡng để đảm bảo rằng nó giải quyết được sự cố và không gây ra bất kỳ sự cố mới nào. Điều này có thể được thực hiện bằng cách tạo một "Pull Request" để hợp nhất nhánh hotfix/hotfix-name vào nhánh "master" để thử nghiệm . Sau khi xem xét và kiểm tra, hotfix có thể được hợp nhất trở lại vào cả hai nhánh "master" và "develop" bằng cách chạy lệnh git flow hotfix finish hotfix-name trong terminal. Thao tác này sẽ hợp nhất các thay đổi trong nhánh hotfix/hotfix-name thành cả "master" và "develop", xóa nhánh hotfix/hotfix-name và chuyển trở lại nhánh "develop". Bằng cách tuân theo mô hình phân nhánh Git Flow cho các nhánh hotfix, các nhóm có thể nhanh chóng giải quyết các sự cố khẩn cấp trong môi trường sản xuất đồng thời duy trì quy trình làm việc có cấu trúc và tổ chức, đảm bảo chất lượng mã và độ ổn định cao, đồng thời tránh xung đột trong quá trình sửa lỗi hotfix.

Quá trình sử dụng Git Flow để hoàn thành một nhánh hotfix bao gồm pull các thay đổi từ các nhánh "develop" và "master" trước khi hoàn thiện nhánh hotfix với git flow hotfix finish hotfix-name. Sau khi hoàn thiện nhánh hotfix, các thay đổi phải được push sang cả nhánh "develop" và "master" bằng cách sử dụng git push và tag được tạo tự động cho phiên bản hotfix. Điều quan trọng là push tag vào kho lưu trữ từ xa để những người khác có thể dễ dàng xác định phiên bản mã nào đang được sử dụng trên production. Để liệt kê tất cả các tag trong kho lưu trữ Git, hãy sử dụng "git tag" và để chuyển sang một tag cụ thể, hãy sử dụng git checkout tag-name. Sử dụng git push --tags hoặc git push origin tag-name để push các tag vào kho lưu trữ từ xa.

Khi sử dụng Git Flow, việc tạo phiên bản cho nhánh hotfix thường yêu cầu tạo số phiên bản mới bằng cách thêm hậu tố để cho biết đó là hotfix, dựa trên phiên bản phát hành trước đó. Ví dụ: nếu phiên bản phát hành trước là 1.0, phiên bản hotfix có thể là 1.0.1 và phiên bản hotfix sau có thể là 1.0.2. Lược đồ phiên bản cụ thể có thể khác nhau tùy thuộc vào tùy chọn của dự án và nhóm. Điều quan trọng là đảm bảo rằng số phiên bản rõ ràng và nhất quán để tránh nhầm lẫn và cho phép dễ dàng theo dõi các thay đổi và các bản phát hành. Sau khi hotfix được hợp nhất trở lại nhánh "master", số phiên bản mới sẽ được cập nhật trong các tệp thích hợp và được commit với nhánh “master”. Điều này đảm bảo rằng số phiên bản mới được phản ánh trong bản phát hành tiếp theo.

Giả sử có một vấn đề nghiêm trọng trên production (với thẻ phiên bản 1.2.0) cần được khắc phục ngay lập tức, Git Flow có thể được sử dụng cho một nhánh hotfix:

• Tạo một nhánh hotfix: Bạn sẽ tạo một nhánh hotfix mới có tên là "1.2.1" bằng cách chạy lệnh git checkout master && git pull && git flow hotfix start 1.2.1. Điều này tạo ra một nhánh mới gọi là "hotfix/1.2.1" dựa trên nhánh "master".
• Tạo hotfix: Sau đó, các nhà phát triển sẽ làm việc để khắc phục sự cố bằng cách thực hiện các thay đổi cần thiết trong nhánh "hotfix/1.2.1". Họ có thể chuyển giao các thay đổi của mình cho nhánh hotfix khi họ làm việc với nó. Ví dụ: git commit -m "Fix critical bug XYZ"
• Kiểm tra hotfix: Sau khi hotfix được tạo, nó cần được kiểm tra kỹ lưỡng để đảm bảo nó giải quyết được sự cố và không gây ra bất kỳ sự cố mới nào. Điều này có thể được thực hiện bằng cách tạo một "Pull Request" để hợp nhất nhánh hotfix/1.2.1 vào nhánh "master" để thử nghiệm.
• Hoàn thiện hotfix: Sau khi hotfix được xem xét và kiểm tra, nó có thể được hợp nhất trở lại vào cả hai nhánh "master" và "develop" bằng cách chạy lệnh: git checkout develop && git pull && git checkout master && git pull && git flow finish hotfix 1.2.1. Thao tác này sẽ hợp nhất các thay đổi trong nhánh "hotfix/1.2.1" thành cả "master" và "develop", xóa nhánh "hotfix/1.2.1" và chuyển bạn trở lại nhánh "develop".
• Để push các nhánh "develop" và "master" cùng với tag mới "1.2.1", hãy thực hiện các lệnh sau: git push origin develop && git push origin master && git push origin 1.2.1

Các nhánh Sửa lỗi (bugfix) và Hỗ trợ (support)

GitFlow sử dụng một nhánh sửa lỗi, đây là một loại nhánh nhằm giải quyết một vấn đề hoặc lỗi cụ thể trong cơ sở mã. Nhánh này được tạo từ nhánh phát hành và sau đó được hợp nhất trở lại vào cả nhánh phát hành (release/release-name) và nhánh phát triển (develop) sau khi thử nghiệm và xác thực thành công.

Để giải quyết một lỗi, quy trình trong GitFlow thường tuân theo các bước dưới đây:

• Xác định vấn đề: Điều này liên quan đến việc xem xét báo cáo lỗi, phân tích phản hồi của người dùng hoặc thực hiện kiểm tra để xác định lỗi hoặc vấn đề cụ thể cần được khắc phục.
• Tạo một nhánh sửa lỗi: Sau khi xác định lỗi, một nhánh sửa lỗi mới sẽ được tạo từ nhánh phát hành mới nhất (release/release-name) và nhánh đó phải có tên phản ánh vấn đề đang được giải quyết.
• Thực hiện các thay đổi cần thiết: Bước tiếp theo là thực hiện các thay đổi sẽ sửa lỗi. Điều này có thể yêu cầu cập nhật các dòng mã cụ thể, sửa đổi tệp cấu hình hoặc thực hiện các điều chỉnh khác đối với cơ sở mã.
• Kiểm tra và xác minh bản sửa lỗi: Điều quan trọng là phải kiểm tra và xác minh rằng bản sửa lỗi hoạt động như mong đợi. Điều này có thể liên quan đến việc chạy thử nghiệm tự động, thực hiện thử nghiệm thủ công hoặc cả hai.
• Hợp nhất bản sửa lỗi vào nhánh phát hành: Sau khi bản sửa lỗi đã được kiểm tra và xác thực, nó sẽ được hợp nhất trở lại nhánh phát hành (release/release-name). Điều này đảm bảo rằng bản sửa lỗi sẽ được đưa vào bản phát hành phần mềm tiếp theo.
• Hợp nhất bản sửa lỗi vào nhánh phát triển: Cuối cùng, bản sửa lỗi phải được hợp nhất trở lại nhánh phát triển để đảm bảo rằng bản sửa lỗi được tích hợp vào tất cả các bản phát hành trong tương lai.

Mặt khác, các nhánh hỗ trợ được tạo từ nhánh "master" trong Git Flow để cung cấp hỗ trợ lâu dài cho một phiên bản phát hành cụ thể của phần mềm. Các nhánh hỗ trợ rất hữu ích trong việc cung cấp các bản sửa lỗi và cập nhật bảo mật cho phiên bản phát hành cụ thể mà không ảnh hưởng đến sự phát triển của các phiên bản mới hơn. Quy ước đặt tên cho các nhánh hỗ trợ bao gồm số phiên bản, chẳng hạn như "support/1.0.x". Các nhánh này thường tồn tại lâu dài và yêu cầu phải có tài liệu cũng như quy trình rõ ràng để quản lý và cập nhật chúng theo thời gian, đặc biệt đối với các ứng dụng quan trọng như phần mềm y tế hoặc tài chính.

Cài đặt Git Flow

Để cài đặt Git Flow trên Ubuntu, bạn có thể bắt đầu bằng cách kiểm tra xem Git đã được cài đặt chưa bằng cách chạy lệnh sudo apt-get update && sudo apt-get install git trong terminal của bạn. Bạn có thể tìm thêm thông tin về Git tại https://vulehuan.com/vi/blog/2023/03/hieu-ve-git-va-cac-he-thong-kiem-soat-phien-ban-khac-43.html. Khi Git được cài đặt, bạn có thể tiến hành cài đặt Git Flow bằng cách chạy sudo apt-get install git-flow. Bạn có thể tìm thấy các tùy chọn cài đặt khác cho các hệ điều hành khác nhau tại https://github.com/nvie/gitflow/wiki/Installation.

Sau khi cài đặt Git Flow, bạn cần khởi tạo nó trong kho lưu trữ Git của mình. Để thực hiện việc này, hãy điều hướng đến thư mục dự án của bạn trong terminal và chạy lệnh git flow init. Thao tác này sẽ nhắc bạn chọn một số tùy chọn cấu hình cho Git Flow, chẳng hạn như tên của các nhánh "master" và "develop" của bạn. Nếu muốn sử dụng các tùy chọn cấu hình mặc định, bạn có thể thêm "-d" khi chạy lệnh git flow init để bỏ qua lời nhắc.

Khi Git Flow được khởi tạo, bạn có thể bắt đầu sử dụng mô hình phân nhánh của nó trong quy trình làm việc của mình. Một số lệnh Git Flow phổ biến bao gồm tạo một nhánh tính năng mới và chuyển sang nhánh đó bằng cách sử dụng git flow feature start [name], kết thúc một nhánh tính năng và hợp nhất các thay đổi trở lại nhánh "develop" bằng cách sử dụng git flow feature finish [name] và xuất bản một nhánh tính năng tới một kho lưu trữ từ xa bằng cách sử dụng git flow feature publish [name]. Để theo dõi một nhánh tính năng từ xa, bạn có thể sử dụng git flow feature track [name] và để kéo các thay đổi từ một nhánh tính năng từ xa, bạn có thể sử dụng git flow feature pull [remote] [name].

Các lệnh tương tự có sẵn cho các nhánh release, hotfix và support. Ví dụ: git flow release start [version] tạo một nhánh phát hành mới, git flow release finish [version] kết thúc một nhánh phát hành và hợp nhất các thay đổi trở lại nhánh "develop" và nhánh "master", và "git flow release publish [version]" xuất bản nhánh phát hành tới kho lưu trữ từ xa. Để theo dõi hoặc kéo các thay đổi từ các nhánh từ xa thuộc các loại này, bạn có thể sử dụng các lệnh "track" hoặc "pull" có liên quan.

Ngoài ra, git flow version hiển thị phiên bản hiện tại của Git Flow, git flow config hiển thị các tùy chọn cấu hình Git Flow và git flow help hiển thị thông tin trợ giúp cho các lệnh Git Flow.

Lưu ý rằng git flow XYZ publish [name] và git push XYZ/[name] đều được sử dụng để push một nhánh XYZ đến một kho lưu trữ từ xa, nhưng chúng có các chức năng khác nhau. git flow XYZ publish [name] xuất bản nhánh feature/release/hotfix/support tới kho lưu trữ từ xa, trong khi git push XYZ/[name] push các thay đổi cục bộ trên nhánh feature/release/hotfix/support tới nhánh từ xa.

Các quy trình Git Workflows được sử dụng rộng rãi khác

• GitLab Flow: GitLab Flow là luồng công việc được tối ưu hóa cho cộng tác và tích hợp liên tục (CI) và được sử dụng bởi GitLab, một công cụ quản lý kho lưu trữ Git phổ biến. Quy trình công việc này nhấn mạnh các nhánh tính năng và yêu cầu hợp nhất, đồng thời phù hợp với các nhóm thuộc mọi quy mô. Để biết thêm thông tin, hãy xem: https://docs.gitlab.com/ee/topics/gitlab_flow.html
• GitHub Flow: GitHub Flow là một luồng công việc nhẹ, dựa trên nhánh được thiết kế để hỗ trợ phân phối và triển khai liên tục và được sử dụng bởi GitHub, một dịch vụ lưu trữ kho lưu trữ Git dựa trên web. Quy trình công việc này nhấn mạnh vào các nhánh tính năng và Pull Request, đồng thời lý tưởng cho các nhóm nhỏ, hoạt động nhanh. Để biết thêm thông tin, hãy xem: https://guides.github.com/introduction/flow/
• OneFlow: OneFlow là một mô hình phân nhánh và quy trình công việc được thiết kế để đơn giản hóa quy trình công việc Git bằng cách sử dụng một nhánh duy nhất và được các công ty như Spotify và Walmart Labs sử dụng. Quy trình công việc này nhấn mạnh vào việc phân phối và triển khai liên tục và phù hợp với các nhóm thuộc mọi quy mô. Để biết thêm thông tin, hãy xem: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow
• Trunk-Based Development (TBD): Phát triển dựa trên thân cây (TBD) là một quy trình công việc nhấn mạnh các nhánh tính năng tồn tại trong thời gian ngắn và tích hợp liên tục và được sử dụng bởi các công ty như Google và Amazon. Quy trình công việc này phù hợp với các nhóm lớn, phân tán và được thiết kế để giảm thiểu xung đột hợp nhất và giảm nguy cơ hồi quy. Để biết thêm thông tin, hãy xem: https://trunkbaseddevelopment.com/
• Forking Workflow: Quy trình công việc này thường được sử dụng trong các dự án nguồn mở, nơi những người đóng góp có thể không có quyền ghi vào kho lưu trữ chính. Thay vào đó, những người đóng góp fork kho lưu trữ chính, thực hiện các thay đổi trong fork của riêng họ, sau đó gửi Pull Request tới kho lưu trữ chính khi các thay đổi của họ đã sẵn sàng. Điều này cho phép cộng tác và đánh giá dễ dàng trong khi vẫn duy trì quyền kiểm soát chặt chẽ đối với kho lưu trữ chính.

Phần kết luận

Tóm lại, Git Flow cung cấp một chiến lược phân nhánh có cấu trúc tốt giúp hợp lý hóa quy trình phát triển phần mềm cho các nhóm. Với Git Flow, các nhóm có thể dễ dàng quản lý nhiều phiên bản cơ sở mã của họ trong khi vẫn duy trì chất lượng mã và độ ổn định hàng đầu. Nhánh hotfix nổi bật như một công cụ có giá trị cho phép các nhóm nhanh chóng giải quyết các sự cố nghiêm trọng trong môi trường sản xuất mà không làm gián đoạn quy trình phát triển thông thường của họ. Tuy nhiên, điều quan trọng là phải tuân thủ các quy trình nhánh hotfix thích hợp, bao gồm lập phiên bản và cập nhật các bản phát hành tiếp theo. Bằng cách áp dụng Git Flow, các nhóm có thể đảm bảo phát triển phần mềm hiệu quả, giảm thiểu lỗi và xung đột, đồng thời cung cấp phần mềm chất lượng cao cho người dùng cuối của họ.