Git-flow và master với nhiều nhánh phát hành song song

Chúng tôi đang cố gắng áp dụng mô hình phân nhánh Git thành công được thực hiện bởi git-flow. Bây giờ, chúng tôi đang làm việc trên ít nhất hai nhánh phát hành, một nhánh dành cho bản phát hành ổn định mới nhất và một nhánh cho bản phát hành tiếp theo ("xem trước"). Điều tôi không hiểu là tại sao tất cả các bản phát hành dường như được "tuyến tính hóa" thành bản chính và được gắn thẻ ở đó. Tại sao không gắn thẻ các bản phát hành trong các nhánh phát hành của họ? Tại sao lại là bậc thầy ? Hoặc tại sao một nhánh phát triển và không sử dụng chủ cho nó?

Trong mô hình git-flow, phiên bản "được phát hành mới nhất" của bạn thực sự ánh xạ tới master, trong khi "bản phát hành xem trước" của bạn ánh xạ tới một releasenhánh git-flow . Nó được tách từ developvà cuối cùng được hợp nhất vào masterkhi bản phát hành thực sự xảy ra. Sau đó, đây sẽ trở thành "bản phát hành mới nhất" của bạn và bạn thường sẽ chỉ sửa các lỗi cho bản phát hành đó, bằng cách sử dụng các hotfixnhánh git-flow . Bằng cách này, của bạn masterluôn thể hiện trạng thái ổn định nhất của phiên bản mới nhất được phát hành.

Nếu bạn muốn sửa lỗi cho các bản phát hành cũ hơn hoặc thực hiện bất kỳ phát triển nào khác ở đó, bạn sẽ supporttách một nhánh từ cam kết thích hợp vào master(bạn sẽ có tất cả các phiên bản từng được tạo ở đó). supportcác nhánh vẫn đang thử nghiệm ( theo tài liệu ) và không được ghi chép đầy đủ. Nhưng như bạn có thể thấy từ trợ giúp dòng lệnh:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

các nhánh này chỉ mới bắt đầu và không có ý định sáp nhập trở lại mastercũng như không develop. Điều này thường tốt, vì các bản sửa lỗi cho các bản phát hành "cổ" hoặc các tính năng được khách hàng yêu cầu triển khai trong các bản phát hành "cổ" không thể hoặc không nên quay trở lại master. Nếu bạn vẫn nghĩ, bạn muốn chuyển một bản sửa lỗi cho dòng phát triển chính của mình (được biểu thị bằng mastervà develop), chỉ cần bắt đầu a hotfix, chọn các thay đổi của bạn và hoàn thành hotfix.

Có vẻ như hầu hết là một mô hình tinh thần với một chút nhấn mạnh vào các nhánh. Tôi đồng ý, bạn chỉ có thể gắn thẻ các cam kết mà bạn phát hành thay vì hợp nhất chúng lại thành chính.

Bức tranh đẹp, mặc dù. Việc hợp nhất mọi thứ trở lại thành bản gốc mang lại dấu hiệu rõ ràng về các bản phát hành theo thứ tự tạm thời thay vì để các thẻ phiên bản nằm rải rác trên biểu đồ.

Tôi nghĩ rằng mô hình này không hoạt động để sửa lỗi trong các phiên bản cũ hơn. Nó làm rối tung thứ tự ngăn nắp.

1. Giả sử chúng tôi đã phát hành Phiên bản 1.0.1 và sau đó đã thêm các tính năng và phát hành 1.1.0.
2. Chúng tôi phát hiện ra một lỗi trong 1.0.1 và muốn sửa nó trong cả hai phiên bản
3. Chúng ta phải thêm 1.0.2 sau 1.1.0 trong bản chính và sau đó trực tiếp hủy bỏ (hoặc trước đó) 1.1.1.

Để trả lời câu hỏi của bạn: Tôi nghĩ đây là một bộ quy tắc tạo ra một mô hình tinh thần đơn giản trong một số trường hợp. Không phải tất cả các quy tắc đều có ý nghĩa từ quan điểm kỹ thuật thuần túy nhưng điều đó không làm cho chúng trở nên tồi tệ. Mô hình tinh thần rất tốt cho loài người.

Cá nhân tôi nghĩ rằng git-flow được đề cập là quá phức tạp.

Nếu bạn đang sử dụng GitHub, hãy thử GitHub flow(như Scott Chacon mô tả).

Nó đặc biệt hữu ích cho việc cộng tác trên nhiều tính năng, xem xét mã và bạn có thể kết hợp nó với giải pháp Tích hợp liên tục của mình bằng cách sử dụng Commit Status API.

CẬP NHẬT : Có một trang web chính thức mới của The GitHub Flow ™

CẬP NHẬT 2 : Có một Hướng dẫn GitHub chính thức mới (và được đơn giản hóa) cho Dòng chảy GitHub ™: https://guides.github.com/introduction/flow/

Trong trường hợp của tôi, tôi có hai phiên bản của cùng một phần mềm mà các thông tin cơ bản giống nhau nhưng mỗi phiên bản có một số tính năng khác nhau.

Vì vậy, tôi tạo hai worktreeđiều đó có nghĩa là, tạo hai nhánh dài hạn có liên quan bên cạnh chủ.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Sau đó, tôi có:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Có một kho lưu trữ, nhưng tôi có 3 thư mục riêng biệt bên cạnh nhau cho mỗi nhánh ở trên. Và thực hiện các thay đổi phổ biến trong tổng thể. sau đó hợp nhất nó với cả hai phiên bản khác.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Các thay đổi cụ thể của từng phiên bản cũng sẽ đi trong thư mục tương ứng và các công việc trên mỗi dự án được tách biệt và IDE sẽ không bị nhầm lẫn.

Hy vọng rằng sẽ giúp.

Hoàn toàn đồng ý với @Mot.

Thật tuyệt khi nghe những câu hỏi tương tự.

Nhóm của chúng tôi cũng được săn lùng để tìm kiếm nhiều mô hình phân nhánh Universal hơn là mô hình Successfull . Như @Mot đã đề cập ở trên - ý tưởng chính là tránh giới thiệu các kho lưu trữ bổ sung để hỗ trợ các nhánh release- * trong các repo * .git riêng biệt vì ví dụ như nó được thực hiện bởi kernel.org cho các bản phát hành ổn định. Nhưng kernel.org làm điều đó vì lợi ích của việc giảm thiểu kích thước tải xuống.

Đối với tôi, có vẻ như sẽ sạch sẽ hơn khi có master làm tuyến chính để phát triển .

Ngoài ra, có một số xung đột trong mô hình hợp nhất phát hành- * để làm chủ và gắn thẻ nó sau đó với ý tưởng

sử dụng tập lệnh hook Git để tự động xây dựng và triển khai phần mềm của chúng tôi tới các máy chủ sản xuất của chúng tôi mỗi khi có cam kết về chính

vì kết thúc (hợp nhất và gắn thẻ) không phải là một giao dịch nguyên tử:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

và nếu git hook bắt đầu xây dựng với hỗ trợ lập phiên bản tự động:

$git describe --tags --long >.ver

thì một phiên bản nhầm lẫn có thể được tạo cho:

$ git merge --no-ff release-1.2

Tôi biết rằng phiên bản trong Successfull giới thiệu một số quy trình phiên bản gập nhưng nó không tự động.

Vì vậy, tổng kết lại - sự khác biệt chính mà chúng tôi giới thiệu với mô hình nhánh cho các bản phát hành- * hợp nhất và gắn thẻ là: - gắn thẻ phát hành khi Tạo nhánh của nó - giữ nhánh của bản phát hành để cho phép duy trì chúng trong tương lai

Nhánh chính LUÔN LUÔN đại diện cho cơ sở mã sản xuất của bạn, do đó bạn luôn hợp nhất mã trở lại thành chính ngay sau khi phát hành sản xuất.

Gắn thẻ được sử dụng để "ghi nhớ" mã chính xác đã được đưa vào bản phát hành sản xuất để bạn có thể quay lại sau và phân tích mã nếu có sự cố.

Với điều này về mặt lý thuyết, sẽ không thành vấn đề nếu bạn gắn thẻ mã của mình trên nhánh phát hành hoặc trên nhánh chính sau khi bạn hợp nhất trở lại với chính. Cá nhân tôi thích gắn thẻ mã trên nhánh phát hành vì đây chính xác là mã đi vào bản dựng / phát hành (giả sử có thể xảy ra sự cố với việc hợp nhất).

Vấn đề với khái niệm nhánh phát triển là nó là một luồng. Brendan trong chủ đề này đã đề cập đến một chiến lược có thể được sử dụng liên quan đến khái niệm nhánh phát triển.