Ưu và nhược điểm của git-flow so với github-flow là gì? [đóng cửa]

Gần đây chúng tôi đã bắt đầu sử dụng GitLab.

Hiện đang sử dụng quy trình làm việc "tập trung".

Chúng tôi đang xem xét chuyển sang github-flow nhưng tôi muốn đảm bảo.

Ưu và nhược điểm của git-flow so với github-flow là gì?

Như đã thảo luận trong GitMinutes tập 17, bởi Nicholas Zakas trong bài viết của anh ấy về " Quy trình làm việc GitHub bên trong một công ty ":

Git-flow là một quy trình để quản lý các thay đổi trong Git do Vincent Driessen tạo ra và kèm theo một số phần mở rộng Git để quản lý luồng đó.
Ý tưởng chung đằng sau git-dòng chảy là có nhiều chi nhánh riêng biệt mà luôn luôn tồn tại, từng cho một mục đích khác nhau: master, develop, feature, release, và hotfix.
Quá trình phát triển tính năng hoặc lỗi diễn ra từ nhánh này sang nhánh khác trước khi cuối cùng được phát hành.

Một số người được hỏi chỉ ra rằng họ sử dụng git-flownói chung.
Một số bắt đầu với git-flowvà rời xa nó.

Lý do chính để chuyển đi là git-flowquá trình khó xử lý trong một mô hình triển khai liên tục (hoặc gần như liên tục).
Cảm giác chung là điều đó git-flowhoạt động tốt đối với các sản phẩm theo mô hình phát hành truyền thống hơn, nơi các bản phát hành được thực hiện vài tuần một lần, nhưng quá trình này bị phá vỡ đáng kể khi bạn phát hành mỗi ngày một lần hoặc hơn .

Nói ngắn gọn:

Bắt đầu với một mô hình càng đơn giản càng tốt (giống như dòng chảy của GitHub) và chuyển sang một mô hình phức tạp hơn nếu bạn cần.

Bạn có thể xem một minh họa thú vị về quy trình làm việc đơn giản , dựa trên GitHub-Flow tại:
" Mô hình phân nhánh git đơn giản ", với các yếu tố chính là:

1. master phải luôn luôn có thể triển khai.
2. tất cả các thay đổi được thực hiện thông qua các nhánh tính năng (pull-request + merge)
3. rebase để tránh / giải quyết xung đột; hợp nhất vàomaster

Để có một quy trình làm việc thực tế hoàn chỉnh và mạnh mẽ hơn, hãy xem gitworkflow (một từ) .

Không có quy trình làm việc viên đạn bạc nào mà mọi người nên tuân theo, vì tất cả các mô hình đều ở mức tối ưu. Phải nói rằng, bạn có thể chọn mô hình phù hợp cho phần mềm của mình dựa trên các điểm dưới đây;

Nhiều phiên bản đang được sản xuất - sử dụng Git-flow

Nếu mã của bạn có nhiều phiên bản đang được sản xuất (tức là các sản phẩm phần mềm điển hình như Hệ điều hành, Gói văn phòng, Ứng dụng tùy chỉnh, v.v.), bạn có thể sử dụng git-flow. Lý do chính là bạn cần liên tục hỗ trợ các phiên bản trước trong quá trình sản xuất trong khi phát triển phiên bản tiếp theo.

Phiên bản đơn trong phần mềm sản xuất đơn giản - sử dụng Github-flow

Nếu mã của bạn luôn chỉ có một phiên bản đang sản xuất (tức là các trang web, dịch vụ web, v.v.), bạn có thể sử dụng github-flow. Lý do chính là bạn không cần phải làm những thứ phức tạp cho nhà phát triển. Sau khi nhà phát triển hoàn thành một tính năng hoặc hoàn thành một bản sửa lỗi, nó ngay lập tức được thăng cấp lên phiên bản sản xuất.

Phiên bản duy nhất trong sản xuất nhưng phần mềm rất phức tạp - sử dụng Gitlab-flow

Phần mềm lớn như Facebook và Gmail, bạn có thể cần giới thiệu các nhánh triển khai giữa nhánh của bạn và nhánh chính nơi các công cụ CI / CD> có thể chạy, trước khi nó đi vào sản xuất. Ý tưởng là tăng cường bảo vệ cho phiên bản sản xuất vì nó được hàng triệu người sử dụng.

Tôi đã sử dụng mô hình git-flow hơn một năm và nó ổn.

Nhưng nó thực sự phụ thuộc vào cách ứng dụng của bạn sẽ được phát triển và triển khai.

Nó hoạt động tốt khi bạn có một ứng dụng có luồng phát triển / triển khai chậm.

Nhưng ví dụ: như GitHub, chúng tôi có một ứng dụng có quy trình phát triển / triển khai nhanh, chúng tôi triển khai hàng ngày và đôi khi vài lần một ngày, trong trường hợp này, git-flow có xu hướng làm chậm mọi thứ theo quan điểm của tôi và tôi sử dụng GitHub lưu lượng.

Điều khác cần xem xét là git-flow không phải là git tiêu chuẩn, vì vậy bạn có thể, và khi tôi nói bạn có thể, ý tôi thực sự là, bạn sẽ tìm thấy các nhà phát triển không biết nó, và sau đó là đường cong học tập, hơn thế nữa cơ hội để làm rối tung mọi thứ. Cũng như đã đề cập ở trên, ai đó đã phát triển một bộ tập lệnh để giúp việc sử dụng git-flow dễ dàng hơn, vì vậy bạn không cần phải nhớ tất cả các lệnh, nó sẽ hỗ trợ bạn với các lệnh, nhưng việc ghi nhớ luồng thực tế là công việc của bạn. , Tôi đã nhiều lần bắt gặp một nhà phát triển không biết liệu đó có phải là một hotfix hay tính năng hay không, hoặc thậm chí tệ nhất là khi họ không thể nhớ quy trình và nội dung.

Có ít nhất một GUI hỗ trợ git-flow cho Mac và Windows SourceTree .

Ngày nay, tôi nghiêng nhiều hơn về luồng GitHub, do tính đơn giản và dễ quản lý của nó. Ngoài ra, vì "thường xuyên triển khai sớm" ...

Hi vọng điêu nay co ich