Có phải tốt hơn để hợp nhất các nhóm thường xuyên hay chỉ sau khi hoàn thành một sự hợp nhất lớn của các nhánh tính năng?

Giả sử nhiều nhánh đang được phát triển, Avà B, cũng như một nhánh "sửa lỗi" gia tăng C.

Bây giờ Cđã "hoàn thành" và sáp nhập vào chủ. Avà Bvẫn đang trong quá trình phát triển và sẽ không được sửa trước khi (có thể) một nhánh sửa lỗi khác được sáp nhập vào master.

Có phải là một ý tưởng tốt để hợp nhất Ccàng sớm càng tốt trong các nhánh tính năng mới? Vì vậy, các tính năng mới ở càng gần mastercàng tốt? Hoặc tốt hơn là để cho tính năng mới được phát triển trong "thế giới" của riêng họ chỉ hợp nhất thành chủ sau khi hoàn thành?

Dù sao cũng sẽ có xung đột, vì vậy cần có thời gian để sửa chúng.

Một nhánh sống càng lâu, nó càng có khả năng phân kỳ khỏi nhánh chính và sự kết hợp phức tạp và phức tạp hơn sẽ xảy ra khi cuối cùng nó kết thúc. Mười xung đột nhỏ dễ giải quyết hơn 1 xung đột lớn và thực sự có thể ngăn các nhà phát triển nhân đôi hoặc lãng phí nỗ lực. Cho rằng, bạn nên hợp nhất mastervào Avà Bthường xuyên; một lần một ngày là một đề xuất khá phổ biến, mặc dù nếu bạn có nhiều hoạt động trên các chi nhánh của mình, bạn có thể muốn hợp nhất nhiều lần trong ngày.

Ngoài việc làm cho giải quyết xung đột dễ dàng hơn, bạn đề cập cụ thể Clà một nhánh lỗi. Là nhà phát triển, tôi muốn chi nhánh của mình có tất cả các lỗi mới nhất, để đảm bảo tôi không lặp lại hành vi dẫn đến lỗi hoặc viết các bài kiểm tra dựa trên dữ liệu sai.

Dù sao cũng sẽ có xung đột, vì vậy cần có thời gian để sửa chúng.

Nếu bạn biết sẽ có xung đột, bạn có thể muốn áp dụng một chiến lược phân nhánh khác. Giữ nhiều thay đổi cho cùng một (các) tệp trên cùng một nhánh bất cứ khi nào có thể và bạn giảm hoặc loại bỏ số lượng xung đột. Câu chuyện tái cấu trúc sao cho chúng hoàn toàn độc lập hết mức có thể và làm lại các nhánh để có thể bao quát nhiều câu chuyện (nhánh, tính năng và câu chuyện không phải lúc nào cũng có thể thay thế cho nhau).

Giả sử ý định của bạn là cuối cùng hợp nhất A, B trở lại thành chủ và duy trì một cơ sở mã duy nhất, không bao giờ là một ý tưởng tốt để đi chệch khỏi chủ quá xa. Đi chệch khỏi chủ quá lâu, đặc biệt là khi sửa lỗi và phát triển khác đang hợp nhất thành chủ vì A, B đang được phát triển, chắc chắn sẽ gây ra xung đột.

Tôi sẽ xem xét các chiến lược tương tự như sau

1. Bất cứ ai chịu trách nhiệm về A, B nên theo dõi tổng thể chặt chẽ và hợp nhất trong mọi thay đổi.
2. Tốt hơn nữa, nếu bạn có bản dựng và kiểm tra tự động hóa, hãy đảm bảo A, B hợp nhất thành chủ và vượt qua các bài kiểm tra hàng đêm.
3. Dựa vào bạn nhận xét câu trả lời khác, dường như A, B có thể mất một thời gian để phát triển. Trong trường hợp này, bạn thậm chí có thể cân nhắc để có A, B hợp nhất với nhau để cuối cùng bạn không gặp khó khăn lớn khi hợp nhất cả hai trở lại thành chủ.
4. Ở cấp độ cao hơn, hãy nghĩ về lý do tại sao bạn cần 2 dòng phát triển dài riêng biệt. Bạn có thể chia thành các sáp nhập nhỏ hơn? Bạn có thể đột nhập vào các dịch vụ vi mô riêng biệt?

Thường thường là tốt hơn so với một đồ sộ.

Yêu cầu kéo nhỏ hơn, thường xuyên hơn, hầu như luôn luôn tốt hơn.

Tôi đã bắt đầu sử dụng các cờ cấu hình chủ yếu để tôi có thể thực hiện sớm các yêu cầu kéo nhỏ hơn để lần lượt tôi có thể hợp nhất mã dễ dàng hơn, nhưng để lại tính năng bị vô hiệu hóa. Yêu cầu kéo càng nhỏ, càng dễ xem lại mã, ngay cả khi có nhiều yêu cầu kéo hơn. Hầu hết mọi người dưới mọi hình thức sẽ không thể thực hiện đánh giá có ý nghĩa về các yêu cầu kéo lớn. Thật khó khăn cho RAM tinh thần của một người để hiểu tất cả những tác động có thể có của một sự thay đổi mã lớn.

Có thêm chi phí trong việc tạo cờ cấu hình, vì vậy nó không xứng đáng với các tính năng nhỏ hơn. Nhưng sau đó yêu cầu kéo của bạn sẽ nhỏ.

Tuy nhiên, có thể có các tình huống trong đó tính năng phải được phát hành cùng một lúc. Thậm chí sau đó có thể tốt hơn để thực hiện các yêu cầu kéo nhỏ hơn đến một chi nhánh khác được thực hiện cho mục đích đó.

Hầu hết các đồng nghiệp của tôi than vãn khi ai đó tạo ra một yêu cầu kéo lớn, và đối với hầu hết các phần, đúng như vậy.

Cũng lưu ý rằng đôi khi tôi cần phải hái anh đào vào một nhánh riêng. Nếu những gì cần được hái anh đào có thể được đưa vào một cam kết duy nhất thì việc di chuyển nó sang các nhánh khác sẽ dễ dàng hơn. Đây là một trường hợp thực sự có ít cam kết là tốt hơn, nhưng nó không chính xác là quy trình tiêu chuẩn nếu bạn hái anh đào xung quanh.

Trong Tái cấu trúc của Martin Fowler, lời khuyên mà ông đưa ra là đừng bao giờ để một nhánh được tách khỏi chủ trong thời gian dài hơn một ngày. IIRC, bạn nên thực hiện một thay đổi nhỏ, kiểm tra để đảm bảo rằng bạn không phá vỡ bất cứ thứ gì, và sau đó hợp nhất lại.

Một tùy chọn khác cho các thay đổi thực sự tồn tại lâu có thể kết thúc nhưng chưa sẵn sàng để sử dụng là đặt chúng phía sau một cờ tính năng để chúng có thể được hợp nhất để làm chủ nhưng không có nguy cơ phá vỡ bất cứ điều gì. Sau đó, khi chúng đã sẵn sàng để sử dụng, cờ tính năng có thể được gỡ bỏ.