Là công ty của tôi sáp nhập chi nhánh sai?

28

Gần đây tôi đã bắt gặp một bài viết của MSDN về phân nhánh và sáp nhập và SCM: Phân nhánh và sáp nhập Primer - Chris Birmele .

Trong bài báo họ nói 'hợp nhất vụ nổ lớn' là một phản đề hợp nhất:

Hợp nhất Big Bang - trì hoãn hợp nhất chi nhánh đến hết nỗ lực phát triển và cố gắng hợp nhất tất cả các chi nhánh cùng một lúc.

Tôi nhận ra rằng điều này rất giống với những gì công ty tôi đang làm với tất cả các ngành phát triển được sản xuất.

Tôi làm việc tại một công ty rất nhỏ với một người đóng vai trò là người đánh giá cuối cùng + cơ quan hợp nhất thân cây. Chúng tôi có 5 nhà phát triển (bao gồm cả tôi), mỗi người trong số chúng tôi sẽ được chỉ định một nhiệm vụ / lỗi / dự án riêng và chúng tôi sẽ tách từng nhánh khỏi thân cây hiện tại (lật đổ) và sau đó thực hiện công việc phát triển trong chi nhánh của chúng tôi, kiểm tra kết quả, viết tài liệu nếu cần, hãy thực hiện đánh giá ngang hàng và vòng phản hồi với các nhà phát triển khác, sau đó gửi chi nhánh để xem xét + hợp nhất trên phần mềm quản lý dự án của chúng tôi.

Sếp của tôi, cơ quan duy nhất trên kho lưu trữ thân cây, sẽ thực sự trì hoãn tất cả các đánh giá của các chi nhánh cho đến khi anh ấy thực hiện đánh giá càng nhiều càng tốt, một số chi nhánh sẽ được gửi lại để cải tiến / sửa lỗi, một số các nhánh sẽ hợp nhất ngay vào thân cây, một số nhánh sẽ bị ném trở lại vì xung đột, v.v.

Không có gì lạ khi chúng ta có 10-20 chi nhánh đang hoạt động trong hàng đánh giá cuối cùng được sáp nhập vào thân cây.

Chúng tôi cũng thường xuyên phải giải quyết xung đột trong giai đoạn xem xét và hợp nhất cuối cùng vì hai nhánh được tạo ra từ cùng một thân cây nhưng đã sửa đổi cùng một đoạn mã. Thông thường chúng tôi tránh điều này bằng cách chỉ tái lập lại thân cây và áp dụng lại các thay đổi của chúng tôi và giải quyết các xung đột sau đó gửi chi nhánh mới để xem xét (người nghèo nổi loạn).

Một số câu hỏi trực tiếp tôi có là:

Có phải chúng ta đang trưng bày các mô hình chống được mô tả là 'hợp nhất vụ nổ lớn'?
Có phải một số vấn đề chúng ta đang thấy là kết quả của quá trình hợp nhất này?
Làm thế nào chúng ta có thể cải thiện quá trình hợp nhất này mà không làm tăng sự tắc nghẽn đối với ông chủ của tôi?

Chỉnh sửa: Tôi nghi ngờ ông chủ của tôi sẽ nới lỏng sự kìm kẹp của mình trên kho lưu trữ trung kế hoặc cho phép các nhà phát triển khác hợp nhất với trung kế. Không chắc lý do của anh ta là gì nhưng tôi không thực sự có kế hoạch đưa chủ đề lên vì nó đã được đưa lên trước và bị bắn hạ khá nhanh. Tôi nghĩ rằng họ không tin tưởng chúng tôi, điều đó không có ý nghĩa bởi vì mọi thứ đều được theo dõi.

Bất kỳ cái nhìn sâu sắc khác về tình huống này sẽ được đánh giá cao.

— người dùng6567423
nguồn

2

Tại sao sáp nhập hoãn lại? Thông thường, có một lý do cho việc không làm điều đó ngay lập tức. Là anh chàng độc thân làm việc quá sức và tồn đọng quá lớn? Có một số lý do khác tại sao việc sáp nhập không được thực hiện kịp thời?

— Polygnome

1

Tôi đã ở một vị trí tương tự như bạn, nhiều lần. Tôi có thể nói từ kinh nghiệm cá nhân rằng nhiều công ty kiểm soát phiên bản, đặc biệt là phân nhánh, sai lầm khủng khiếp.

— MechMK1

3

Điều gì xảy ra khi ông chủ đi nghỉ?

— Liath

Làm thế nào bạn sẽ xác định chiến lược phân nhánh / hợp nhất hạt nhân linux?

— Braiam

Các thay đổi bị ném trở lại do xung đột nhưng không phải là các khiếm khuyết khác cần phải thực hiện lại quy trình phê duyệt một khi các xung đột được giải quyết hoặc chúng được coi là "được phê duyệt tạm thời"?

— Gregory Nisbet

60

Một số gợi ý:

Không có gì sai khi có nhiều nhánh tính năng hoặc lỗi, miễn là các thay đổi được thực hiện trong mỗi nhánh đủ nhỏ, bạn vẫn có thể xử lý các xung đột hợp nhất kết quả một cách hiệu quả. Đó phải là tiêu chí của bạn nếu cách làm việc của bạn ổn, không phải là một số bài viết MSDN.
Bất cứ khi nào một nhánh được hợp nhất vào thân cây, thân cây nên được sáp nhập vào tất cả các nhánh phát triển mở càng sớm càng tốt. Điều này sẽ cho phép tất cả mọi người trong nhóm giải quyết các xung đột hợp nhất song song trong nhánh riêng của họ và do đó chịu một số gánh nặng từ người gác cổng của thân cây.
Điều này sẽ hoạt động tốt hơn nếu người gác cổng không chờ đợi cho đến khi 10 chi nhánh "sẵn sàng để hợp nhất vào thân cây" - giải quyết xung đột hợp nhất từ các tích hợp thân cuối cùng luôn cần một thời gian cho nhóm, vì vậy có lẽ tốt hơn để làm việc trong các khoảng thời gian đan xen - một tích hợp bởi người gác cổng, một tích hợp lại bởi nhóm, tích hợp tiếp theo bởi người gác cổng, tiếp theo hợp nhất lại bởi nhóm, v.v.
Để giữ cho các nhánh nhỏ, có thể giúp phân chia các tính năng lớn hơn thành nhiều nhiệm vụ nhỏ hơn và phát triển từng nhiệm vụ đó trong một nhánh của chính nó. Nếu tính năng này chưa sẵn sàng sản xuất cho đến khi tất cả các nhiệm vụ được triển khai, hãy ẩn nó khỏi sản xuất đằng sau một tính năng chuyển đổi cho đến khi tất cả các nhiệm vụ được hoàn thành.
Sớm hay muộn bạn sẽ gặp phải các tác vụ tái cấu trúc ảnh hưởng đến nhiều tệp trong cơ sở mã - chúng có nguy cơ cao gây ra nhiều xung đột hợp nhất với nhiều nhánh. Chúng có thể được xử lý tốt nhất bằng cách liên lạc rõ ràng với chúng trong nhóm và đảm bảo xử lý chúng chính xác như tôi đã viết ở trên: bằng cách tích hợp chúng trước vào tất cả các nhánh dev trước khi tái hòa nhập và chia chúng thành các cấu trúc lại nhỏ hơn.
Đối với quy mô nhóm hiện tại của bạn, có một người gác cổng duy nhất vẫn có thể hoạt động. Nhưng nếu đội của bạn sẽ tăng kích thước, không có cách nào để có người gác cổng thứ hai (hoặc hơn). Lưu ý Tôi không đề xuất cho phép mọi người hợp nhất vào thân cây, nhưng điều đó không có nghĩa là chỉ có sếp của bạn có khả năng làm việc này. Có lẽ có một hoặc hai nhà phát triển cấp cao cũng có thể là ứng cử viên để thực hiện công việc của người gác cổng. Và ngay cả đối với quy mô nhóm hiện tại của bạn, một người gác cổng thứ hai có thể giúp nhóm của bạn dễ dàng tích hợp vào thân cây thường xuyên hơn và sớm hơn hoặc khi sếp của bạn không có mặt.

— Bác sĩ Brown
nguồn

2

Tôi nghĩ rằng bạn có nhận xét tốt nhất ở đây, thừa nhận rằng chúng tôi không thể đơn giản mở thân cây cho mọi người và rằng các nhánh của chúng tôi không thực sự luôn là một vấn đề (chỉ khi chúng xung đột). Tôi nghĩ bạn đã làm rất tốt khi chỉ ra làm thế nào chúng ta có thể giảm xung đột và đảm bảo chu trình hợp nhất diễn ra suôn sẻ, tôi cũng nghĩ bạn hoàn toàn chính xác khi bạn nói rằng chúng ta có thể cần một người gác cổng khác. Cảm ơn rất nhiều cho cái nhìn sâu sắc này!

— dùng6567423

@ user6567423 Một điều khác bạn có thể muốn xem xét là tạo các nhánh cho từng phiên bản phát triển (ví dụ: 5.2.3 hoặc bất cứ thứ gì), mỗi nhà phát triển có thể tách ra để làm việc với tính năng và sau đó hợp nhất lại, và sau đó có thể được hợp nhất trở lại vào chính phát hành chi nhánh của ông chủ khi phát triển hoàn tất.

— nick012000

@ nick012000: đề xuất đó sẽ không khiến người gác cổng khó chấp nhận hoặc từ chối các nhánh tính năng cá nhân để / chống tích hợp vào thân cây? Ý tôi là, nếu một số tính năng được trộn lẫn vào một nhánh phát triển, việc tái hòa nhập những thay đổi đó một phần vào thân cây sẽ trở nên thực sự khó khăn. Hay tôi đang thiếu một cái gì đó?

— Doc Brown

10

"Giải quyết xung đột song song trong chi nhánh của chính họ và do đó chịu một chút gánh nặng từ người gác cổng của thân cây. " - Tôi cảm thấy như phần này bị giảm một cách bất công sang một ghi chú bên lề. "Tốt hơn cho công ty NHƯNG dễ dàng hơn cho bạn " dường như là điểm bán hàng chính khi đề xuất điều này với ông chủ. Điều đó đi sâu hơn vào chính trị văn phòng chỉ đạo, mà SE không hướng tới - nhưng trong tình huống này, không có sự mua lại từ ông chủ, mọi thứ khác trong câu trả lời tuyệt vời về mặt kỹ thuật này sẽ không xảy ra.

— R. Schmitz

@DocBrown Vâng, điều đó cũng có nghĩa, nhưng điều đó cũng có nghĩa là bạn sẽ có ít xung đột hơn giữa các nhánh dev và nó vẫn mang lại cho bạn mức độ an toàn khi không sáp nhập trực tiếp vào nhánh chính - và anh ta có thể đơn giản từ chối chấp nhận công việc là Xong và thực hiện hợp nhất cho đến khi anh ấy hài lòng với toàn bộ trạng thái của mã.

— nick012000

18

Có phải chúng ta đang trưng bày các mô hình chống được mô tả là 'hợp nhất vụ nổ lớn'?

Âm thanh như thế.

Có phải một số vấn đề chúng ta đang thấy là kết quả của quá trình hợp nhất này?

Chắc chắn

Làm thế nào chúng ta có thể cải thiện quá trình hợp nhất này mà không làm tăng sự tắc nghẽn đối với ông chủ của tôi?

Tại công ty của tôi, mọi nhà phát triển đều có khả năng hợp nhất. Chúng tôi chỉ định Yêu cầu Hợp nhất cho nhà phát triển khác, trải qua chu trình xem xét / phản hồi / cập nhật cho đến khi cả hai bên hài lòng. Sau đó, người xem xét hợp nhất mã.

10-20 chi nhánh đang chờ để được sáp nhập là một dấu hiệu cho thấy quy trình của bạn bị thiếu sót. Nếu chúng ta có nhiều như vậy, tất cả các công việc dev sẽ dừng lại cho đến khi nó bị xóa.

— Matthew
nguồn

1

Không phải là câu trả lời tôi đang tìm kiếm bởi vì tôi nghi ngờ ông chủ của tôi sẽ nới lỏng sự kìm kẹp của mình trên kho lưu trữ thân cây. Nhưng một câu trả lời cực kỳ hữu ích không hơn không kém, cảm ơn vì sự sáng suốt!

— dùng6567423

5

@ user6567423: Nếu sếp của bạn trở thành nút cổ chai, mà bây giờ anh ấy theo mô tả của bạn, anh ấy sẽ phải thay đổi cách tiếp cận của mình hoặc chấp nhận rằng anh ấy là nguyên nhân của sự chậm trễ (mà nhân viên của anh ấy sau đó không thể đổ lỗi cho). Từ chối thay đổi cách tiếp cận của bạn, bỏ qua các vấn đề bạn đang tạo ra và đổ lỗi cho người khác không phải là cách điều hành doanh nghiệp.

— Flater

1

Anh ta đồng ý rằng anh ta là nút cổ chai và anh ta chắc chắn không đổ lỗi cho người khác về điều đó. Nhưng vâng, tôi đang tìm kiếm bất kỳ lời khuyên nào có thể không rõ ràng có thể làm giảm sự tắc nghẽn của chúng tôi. Cảm ơn về cái nhìn sâu sắc

— user6567423

1

@ user6567423 Tôi tò mò liệu anh ta có bao giờ giải thích tại sao anh ta là người duy nhất có thể hợp nhất vào thân cây không.

— Matthew

13

Đây thực chất là cách mà rất nhiều dự án nguồn mở hoạt động, trong đó đáng chú ý nhất là nhân Linux, có nhiều nhánh bay hơn bạn làm bất cứ lúc nào. Cách điển hình để tránh sáp nhập lớn trong các dự án này là tạo một chi nhánh khác (hoặc nhiều chi nhánh) để tích hợp liên tục. Đây là chi nhánh bạn sử dụng để đảm bảo các thay đổi của bạn hoạt động cùng với các đồng nghiệp của bạn và nó được định kỳ khởi động lại trên thân cây khi người gác cổng đi xung quanh để thực hiện đánh giá.

Tùy chọn, bạn có thể sử dụng chi nhánh này để kết hợp một số yêu cầu kéo của riêng bạn thành một yêu cầu gắn kết lớn để sếp của bạn xem xét. Linus Torvalds thường nhận được các yêu cầu kéo đã được tích hợp sâu hai cấp trở lên và có thể có kích thước theo thứ tự, ví dụ, trình điều khiển hệ thống tệp hoàn chỉnh mới.

— Karl Bielefeldt
nguồn

Cảm ơn tôi nghĩ rằng các mẹo kết hợp các nhánh và ngăn ngừa xung đột có lẽ sẽ là cách hành động tốt nhất của chúng tôi.

— dùng6567423

8

Tôi đồng ý với cả Doc Brown nhưng tôi cũng thấy một antipotype khác:

Sếp của tôi, cơ quan duy nhất trên kho lưu trữ thân cây , sẽ thực sự trì hoãn tất cả các đánh giá về các chi nhánh cho đến khi anh ấy thực hiện đánh giá càng nhiều càng tốt, một số chi nhánh sẽ được gửi lại để cải tiến / sửa lỗi, một số các nhánh sẽ hợp nhất ngay vào thân cây, một số nhánh sẽ bị ném trở lại vì xung đột , v.v.

Trong khiêm tốn của tôi có một số antipotype quản lý:

Anh ấy / cô ấy là điểm sặc duy nhất kìm hãm vận tốc của đội. Hệ số xe buýt của bạn là 1. Lý thuyết về các ràng buộc nói rằng bạn nên nỗ lực cải thiện phần chậm nhất của chuỗi.
Người quản lý của bạn đang làm cho chu kỳ phản hồi của bạn chậm hơn và giảm sự nhanh nhẹn của nhóm của bạn. Bạn có thể phát hành mỗi tuần?
Sáp nhập phức tạp tăng theo cấp số nhân với số lượng mã. Tốt hơn là thực hiện 10 hợp nhất với 100 dòng hơn 1 trên 1000 dòng. Đó chỉ là một trong những lý do tại sao bạn nên làm điều đó càng sớm càng tốt
Nếu bạn phát hiện ra một lỗi trong thân cây, bạn sẽ thực hiện nó sau. Mà một trong những chi nhánh là một trong những vấn đề
Quyết định nên được thực hiện bởi những người có nhiều kiến thức về họ. Ai biết nhiều hơn trong trường hợp này? Tôi đặt cược rằng các nhà phát triển đã tạo ra mã.
Bạn không thể sửa một lỗi trong sản xuất nếu người quản lý của bạn đang sử dụng holydays.
Bạn đang làm lại công việc và ném lại chi nhánh. Đây là một sự lãng phí thời gian. Thời gian chờ đợi để đạt được sản xuất cũng là lãng phí.

Giới thiệu:

Người quản lý của bạn cần ủy thác khả năng đáp ứng cho nhóm. Bạn cần thể hiện rằng đội ngũ trưởng thành, chuyên nghiệp. Làm rõ rằng họ có thể tin tưởng vào đội
Thực hiện một số phương pháp xem xét. Có thể bạn cần sự chấp thuận của hai thành viên khác trong nhóm.
Có thể sử dụng SVN đang làm cho nó khó hơn. Hãy thử Git và xem nếu nó giúp bạn. Thậm chí nhiều hơn. Nếu bạn sử dụng GitHub, bạn có thể sử dụng cơ chế Yêu cầu kéo để việc hợp nhất yêu cầu một số phiếu nhất định.
Đọc và chia sẻ thông tin về các thực hành nhanh, tích hợp liên tục và DevOps.

— Borjab
nguồn

7

Tôi đã làm việc chuyên nghiệp với cả SVN và git, và tôi nói rằng SVN chắc chắn là một phần của vấn đề: Nó buộc một chính sách cam kết hợp nhất duy nhất đối với các chi nhánh không có trong git. Trong git, tất cả các sự hợp nhất là bằng nhau, trong SVN, một số bằng nhau hơn so với những người khác. Ngoài ra, việc thiếu các cam kết cục bộ khiến cho việc thử nghiệm với SVN khó khăn hơn nhiều so với git và việc thiếu khu vực tổ chức chỉ làm tăng thêm tính không linh hoạt của SVN. Có một lý do tại sao Torvalds không chỉ sử dụng SVN thay vì phát triển git ...

— cmaster

Theo ý kiến của tôi, Git tốt hơn nhiều so với svn vì những lý do @cmaster đặt ra và hơn thế nữa

— reggaeg Ức

Tôi đồng ý git có thể sẽ giải quyết một số vấn đề hợp nhất của chúng tôi, và chúa ơi tôi rất muốn có rebase. Nhưng tôi không nghĩ rằng chúng tôi sẽ sớm thực hiện chuyển đổi :(

— user6567423

1

@ user6567423, tôi đã tham khảo năm ngoái khi tôi giúp một nhóm nhỏ chuyển từ svn sang Git và thay đổi quy trình làm việc của họ, bao gồm đào tạo họ trên Git và thiết lập chúng với phiên bản cộng đồng GitLab (là nguồn mở) để đánh giá và cộng tác mã . Họ đã rất nhiệt tình về nó; đó là một sự khác biệt ngày và đêm. (Ngoài ra, chỉ mất ba ngày.)

— Wildcard

2

Khi bạn thực hiện công việc tính năng trong các nhánh riêng biệt, bạn không thể dễ dàng thực hiện bất kỳ thử nghiệm tích hợp nào cho đến khi một trong các nhánh được hợp nhất vào thân cây và kéo vào các nhánh tính năng khác. Theo kinh nghiệm của tôi, đây là vấn đề chính với mô hình chống Big Bang Merge. Lý tưởng nhất là bạn sẽ thực hiện công việc tính năng, kiểm tra nó trong nhánh tính năng, hợp nhất nó vào thân cây và tại thời điểm đó bạn đã hoàn thành tính năng này. Nếu nó chưa được hợp nhất, bạn phải xem lại nó mỗi khi một thứ khác được hợp nhất vào thân cây trước nó. Nỗi đau của mô hình chống này là bạn có rất nhiều lỗi loại tích hợp xuất hiện ở cuối chu kỳ phát triển.

— bmm6o
nguồn

1

Vậy là bạn có 20 chi nhánh. Chi nhánh 1 vừa được sáp nhập. Sau đó, nhà phát triển của nhánh 2 phải hợp nhất nhánh 1 vào nhánh của họ để có thể hợp nhất thành chính mà không bị xung đột, sau đó hợp nhất. Sau đó, nhà phát triển của nhánh 3 phải hợp nhất nhánh 1 và nhánh 2 vào nhánh của họ để có thể hợp nhất thành chính mà không bị xung đột, sau đó hợp nhất.

Bài tập cho người đọc: Viết chương trình in bài hoàn chỉnh của tôi :-)

Đây là sự điên rồ. Bạn sẽ dành một lượng thời gian đáng kinh ngạc để hợp nhất.

— gnasher729
nguồn

Cũng không nhất thiết, trừ khi các chi nhánh có xung đột thì anh ta chỉ có thể hợp nhất tất cả chúng vào thân cây một cách liền mạch. Chúng tôi thường sẽ cố gắng ngăn chặn mọi xung đột bằng cách thực hiện kiểm tra hợp nhất trước khi chúng tôi gửi chi nhánh để xem xét nhưng các xung đột xuất hiện chắc chắn khi số lượng chi nhánh trong hàng đợi tăng lên. Tôi đồng ý rằng nó có vẻ như điên rồ.

— dùng6567423

2

Hành vi hợp nhất SVN bình thường, theo như tôi có thể nói ...

— cmaster

0

Với cách bạn đang làm việc và sếp của bạn là một người thích kiểm soát có trách nhiệm, việc phân nhánh dường như là vấn đề. Thay vì tạo một nhánh cho mọi tính năng, hãy để mỗi nhà phát triển cam kết tính năng của mình theo từng phần, trực tiếp vào thân cây. Điều này đặt gánh nặng tích hợp lên nhà phát triển theo nhiều bước nhỏ hơn (win-win). Người giữ cổng có thể theo kịp các thay đổi nhỏ hơn trong một khoảng thời gian dài hơn trước đó trong chu kỳ phát triển và vẫn là người đánh giá chính.

Phân nhánh chính nó là điều bạn không muốn làm trừ khi bạn có lý do rất chính đáng để làm điều đó hoặc bạn không có lựa chọn nào khác. Bạn đủ nhỏ để giữ mọi thứ đồng bộ chặt chẽ hơn, điều này sẽ dễ dàng và an toàn hơn.

— Martin Maat
nguồn

1

Và bạn sẽ xử lý việc phát hành như thế nào nếu chỉ 1 trong số các tính năng đó có lỗi hoặc không hoàn thành đúng lúc? "Phân nhánh chính là điều bạn không muốn làm trừ khi bạn có lý do rất chính đáng để làm" - Một khi bạn có 5 người làm việc trên nhiều tính năng, bạn phải sử dụng phân nhánh trừ khi bạn không có lý do rất chính đáng.

— Ivo van der Veeken

Đó là về hai điều: ông chủ muốn vẫn là người giữ cổng duy nhất và duy nhất và mọi thứ không được phép phân kỳ quá nhiều. Vâng, sẽ có một khoảnh khắc mà một cái gì đó được đẩy mà vẫn chưa được sếp xem xét kỹ lưỡng. Anh ta có thể làm điều đó một cách nhanh chóng và trong trường hợp không chắc anh ta cần giao ngay lập tức anh ta có thể hoàn nguyên các cam kết mới nhất. Điều này sẽ giữ mọi thứ đồng bộ và nếu bạn thất bại ở bất cứ điều gì, bạn chắc chắn sẽ thất bại nhanh chóng. Có vẻ như một sự thỏa hiệp tốt với tôi cho tình huống trong tay.

— Martin Maat

1

Tôi sẽ coi đây là phương sách cuối cùng

— reggaeg Ức