Xu hướng phát triển chi nhánh của người Viking sẽ biến mất

Gần đây tôi đã nhận thấy một cái gì đó nhìn vào một số dự án phổ biến trên GitHub, rằng không có developchi nhánh. Và trên thực tế, hướng dẫn GitHub Flow cũng không đề cập đến nó. Từ hiểu biết của tôi, masternên luôn luôn hoàn toàn ổn định và phản ánh sản xuất. Nếu các nhà phát triển đang làm việc trên các nhánh tính năng và sau đó hợp nhất chúng vào masterkhi chúng được thực hiện, điều đó có nghĩa là có một khoảng thời gian mà các tính năng / sửa lỗi được sáp nhập vào mastervà masternhánh thực sự mới hơn so với sản xuất.

Sẽ không có ý nghĩa hơn khi nhóm tạo ra tính năng / sửa chữa các nhánh develop, hợp nhất trở lại vào đó, và khi phiên bản tiếp theo hoàn toàn sẵn sàng để phát hành, developđược sáp nhập mastervà một thẻ được tạo ra? Hãy tưởng tượng nếu mọi người đang hợp nhất trực tiếp mastervà một lỗi được báo cáo trong sản xuất trở nên khó khắc phục vì mastercơ sở mã cơ sở đã thay đổi đáng kể. Sau đó, các nhà phát triển chỉ cần thông báo cho người dùng chờ đến bản phát hành tiếp theo để xem vấn đề được giải quyết.

EDIT: Câu hỏi này khác với "đến chi nhánh hay không phân nhánh." Nó đặc biệt đề cập đến những người chuyển sang sử dụng nhánh phát triển và những lý do xung quanh, vì điều đó được quảng cáo là một cách thực hành tốt nhất trong một thời gian dài.

Nó xuất phát từ tư duy CI nơi có sự tích hợp nhiều lần trong ngày.

Có những ưu và nhược điểm của cả hai.

Trong nhóm của chúng tôi, chúng tôi đã từ bỏ chi nhánh phát triển vì chúng tôi cảm thấy nó không mang lại lợi ích bổ sung nào ngoài một vài nhược điểm. Chúng tôi đã định cấu hình phần mềm CI (Teamcity) để bù đắp cho những nhược điểm:

1. Cho phép triển khai một cam kết cụ thể. Nói cách khác: Chúng tôi không triển khai một chi nhánh. Chúng tôi triển khai một cam kết.
2. Chúng tôi có thể triển khai một trong hai chủ hoặc các nhánh bắt đầu bằng một hotfix / tiền tố.

Lý do điều này hoạt động là vì tất cả các yêu cầu kéo đều chứa mã có thể tin cậy được nhưng điều này không có nghĩa là chúng tôi triển khai tất cả các cam kết trong tổng thể.

Lý do chính khiến chúng tôi từ bỏ chi nhánh phát triển là vì nó có xu hướng quá lớn và quá tốn thời gian để xem những gì nó thực sự chứa. Nếu chúng tôi đã triển khai một cái gì đó sớm một chút, chúng tôi chỉ cần phân nhánh một nhánh hotfix và triển khai trực tiếp.

Một nhánh phát triển quan trọng hơn nếu quy trình phát hành của bạn phức tạp và bạn cần phải có những ứng cử viên phát hành nghiêm túc.

Ví dụ, hãy tưởng tượng bạn đang viết phần mềm là chương trình cơ sở trên ô tô. Đây là ... không tầm thường để sửa chữa và có khả năng bất kỳ bản phát hành nào cũng sẽ có một bộ kiểm tra tích hợp không CI / tích hợp toàn diện chạy trên phần cứng thực.

Trong trường hợp đó, có thể có ý nghĩa hơn khi cô lập một "ứng cử viên phát hành" trong một nhánh không chính chủ (chẳng hạn như "phát triển"). Điều đó cho phép nhóm của bạn chạy các thử nghiệm đó để có một nhánh để hợp nhất các tính năng vào.

Webapps hoặc phần mềm dễ dàng cập nhật khác không có ràng buộc này.

Tuy nhiên, lưu ý rằng:

• Nhiều dự án (hầu hết?) Trên github không có loại ràng buộc này
• Một "chủ" chính phục vụ cùng một mục đích
• Quy trình "tạo PR so với chủ" phổ biến hơn nhiều so với "tạo PR cho một chi nhánh mà bạn không biết ngay lập tức trên repo này"

Có hai triết lý tôi từng thấy trong các dự án và tôi nghĩ rằng sự lựa chọn chỉ là vấn đề của hương vị:

1. Chỉ định 'chủ nhân' là bản phát hành sản xuất và phát triển trong một nhánh 'phát triển'.

2. Phát triển trong 'master' và có một chi nhánh được đặt tên khác để phát hành sản xuất ổn định. Điều này càng có ý nghĩa hơn nếu dự án của bạn có nhiều nhánh phát hành cùng một lúc (ví dụ: dự án ưa thích hiện tại là Phiên bản 1.8, nhưng bạn vẫn đang duy trì Phiên bản 1.7).

Cả hai đều là phương pháp phổ biến, và có ưu và nhược điểm của chúng.

Các bản phát hành có thể được gắn thẻ, vì vậy tình huống được phát hành luôn có thể được sao chép mà không dành toàn bộ chi nhánh cho mục đích này.

Nếu một lỗi nghiêm trọng được tìm thấy trong sản xuất tại thời điểm mà bản gốc không thể được phát hành, thì việc kiểm tra thẻ và bắt đầu một nhánh "hotfix-for-release-1.2.0" mới là đủ dễ dàng. Nhưng điều đó nên khá hiếm.

Hầu hết thời gian trong các ứng dụng web của chúng tôi, master đã thay đổi kể từ lần phát hành trước nhưng không đáng kể lắm, vì vậy chúng tôi chỉ có thể thực hiện một bản phát hành mới từ master có bản sửa lỗi. Nó giúp để phát hành rất thường xuyên anyway.

Nếu các nhà phát triển đang làm việc trên các nhánh tính năng và sau đó hợp nhất chúng thành chủ khi chúng được thực hiện, điều đó có nghĩa là có một khoảng thời gian mà các tính năng / sửa lỗi được sáp nhập vào mastervà masternhánh thực sự mới hơn so với sản xuất.

...

Hãy tưởng tượng nếu mọi người đang hợp nhất trực tiếp vào chủ và một lỗi được báo cáo trong sản xuất trở nên khó khắc phục vì cơ sở mã cơ sở đã thay đổi đáng kể.

Đó không phải là Github Flow.

Đây là quy trình triển khai / hợp nhất Github Flow, theo liên kết của bạn:

Triển khai

Khi yêu cầu kéo của bạn đã được xem xét và chi nhánh vượt qua các bài kiểm tra của bạn, bạn có thể triển khai các thay đổi của mình để xác minh chúng trong sản xuất. Nếu chi nhánh của bạn gây ra sự cố, bạn có thể khôi phục lại bằng cách triển khai bản gốc hiện có vào sản xuất.

Hợp nhất

Bây giờ các thay đổi của bạn đã được xác minh trong sản xuất, đã đến lúc hợp nhất mã của bạn vào nhánh chính.

(Nhấn mạnh của tôi)

Nói cách khác, mastersẽ không bao giờ đi trước sản xuất. Tương tự như vậy, mastersẽ luôn ở trạng thái ổn định, có thể giải phóng được (ngoài các lỗi chưa được phát hiện), vì mọi thứ đều được xem xét, thử nghiệm và đưa vào sản xuất trước khi sáp nhập master.

Vấn đề tôi thấy là việc triển khai / hợp nhất luồng Git / Hub giả định rằng một tính năng đang được phát triển / thử nghiệm / hợp nhất / triển khai tại một thời điểm - và thường theo kinh nghiệm của tôi, đây không phải là trường hợp. Nếu chúng tôi hợp nhất một tính năng tại một thời điểm, sẽ có cơ hội lớn hơn cho các vấn đề hồi quy - chỉ được tìm thấy sau khi các tính năng được hợp nhất thành chủ và có thể trong sản xuất.

Cần có một cách để kiểm tra nhiều tính năng, hợp nhất nhiều tính năng và triển khai giống nhau. Tôi đã sử dụng một "nhánh bó" (một nhánh được tạo từ chủ với các nhánh tính năng sẵn sàng thử nghiệm được sáp nhập vào nó) được triển khai thành qa / uat. Sửa chữa trong uat chỉ xảy ra trên nhánh tính năng và những sửa đổi được hợp nhất lại với nhánh gói. Sau khi phần phụ của nhánh được chấp thuận, chỉ những tính năng được phê duyệt trong gói mới được yêu cầu kéo để làm chủ - và chu trình là liên tục.

Tôi sử dụng nó với Gitflow, nhưng cân nhắc sử dụng nó cho luồng GitHub. QA / UAT nhiều tính năng tại một vấn đề thời gian có vẻ quan trọng. Một vấn đề khác với luồng GitHub là nó giả định tất cả các nhà phát triển sr và điều đó không phải lúc nào cũng đúng.

Tôi thà sử dụng luồng GitHub do tính đơn giản của nó. Với tính năng như một gói, tôi nghĩ rằng nó sẽ sẵn sàng hơn. Tôi có thể gói tương tự như phát hành; Tuy nhiên, tôi vẫn đang cân nhắc điều này là tốt.

Một vấn đề khác là quá trình yêu cầu kéo xảy ra ở cuối trước khi hợp nhất với chủ; tuy nhiên, đôi khi bạn muốn xem lại mã trước khi thử nghiệm qa doanh nghiệp - do đó cũng trước khi hợp nhất