Chiến lược hợp nhất Git cho quy trình phân nhánh Agile

Question

Chúng tôi đang áp dụng chính sách phân nhánh mới để làm việc với Agile và cho phép chúng tôi phát hành trên tính năng theo cơ sở tính năng, theo đó chúng tôi có chi nhánh master và chi nhánh QA làm ngành vĩnh viễn. Các bản dựng ban đêm sẽ dựa trên QA và các bản phát hành sẽ có từ master. Các nhà phát triển sẽ tạo ra một chi nhánh tính năng cho mỗi câu chuyện. Tất cả các chi nhánh tính năng sẽ được phân nhánh theo số master và sau đó hợp nhất thành QA để thử nghiệm, sau đó hợp nhất chi nhánh tính năng vào master để phát hành tiếp theo. Điều này là tốt, cho đến khi các tình huống sau:

• Developer A ("Rod") đã tạo ra feature/RodsFeature, thực hiện một số công việc và sáp nhập vào QA (nhưng chưa master)
• Nhà phát triển B ("Jane") đã tạo feature/JanesFeature, thực hiện một số công việc và bây giờ đang cố gắng nhập vào QA
• Merge xung đột đang xảy ra cho Jane, gây ra bởi những thay đổi giới thiệu với QA bởi merge của feature/RodsFeature

Rod

Nếu Jane bỏ qua QA và hợp nhất feature/JanesFeature vào master, sẽ không có xung đột nào như feature/RodsFeature chưa có trong số master. Tuy nhiên, Jane phải hợp nhất thành QA vì lý do hiển nhiên. Để giải quyết xung đột, cô có thể kéo và tích hợp các thay đổi của Rod vào nhánh tính năng của mình, giải quyết xung đột và sau đó tiến hành hợp nhất - với kết quả không mong muốn khi cô hợp nhất chi nhánh của mình thành master. vẫn đang chờ kiểm tra QA.

Vì vậy, giải pháp thay thế sẽ là giải quyết xung đột trực tiếp trên chi nhánh QA, để nguyên chi nhánh của Jane còn nguyên vẹn để sau này hợp nhất thành master. Tuy nhiên, điều này phá vỡ các chính sách xem xét mã, vì việc hợp nhất phải được chấp thuận bởi một người ngang hàng - bằng cách thực hiện điều này, cô đã hợp nhất thành QA cục bộ và được đẩy tới điều khiển từ xa mà không cần bất kỳ yêu cầu kéo hoặc đánh giá ngang hàng nào.

Điều gì sẽ được coi là 'thực hành tốt nhất' trong tình huống này?

Answer 1

Kiểm tra luồng Git. Nó đến gần nhất với những gì bạn đang cố gắng để đạt được.

Nhà phát triển sẽ chia nhánh chi nhánh của họ ra khỏi chi nhánh qa (được gọi là develop trong Luồng Git). hoàn thành tính năng của họ (thường xuyên chọn trạng thái mới nhất của QA) và hợp nhất trở lại develop bất cứ khi nào có thể (một tính năng hoàn tất hoặc ở trạng thái ổn định hoặc bị tắt).

Những gì bạn chạy làm chi nhánh qa có thể là chi nhánh release trong Gitflow.

Mọi thay đổi đối với chương trình chính sẽ được hợp nhất ngay lập tức trở lại develop.

Xem thêm:

• https://www.atlassian.com/git/tutorials/comparing-workflows/

Answer 2

tl; dr: thêm chi nhánh dev để thực hiện yêu cầu kéo của nhánh 'nhiệm vụ' cụ thể với các thay đổi cho đánh giá mã. Trên một số dự án nhóm tôi đã ở đó cũng là chi nhánh dev để thực hiện "yêu cầu kéo" trên Github hoặc một người quản lý kho lưu trữ, nơi một nhà phát triển cao cấp xem xét những gì đã thay đổi và xem liệu thay đổi cụ thể đó có được viết hay không ...

Trong môi trường lưu trữ repo trực tuyến như Github, chúng có hiển thị rõ ràng các thay đổi ngược lại với nhánh ban đầu, v.v. Sau khi xem chi nhánh, nhà phát triển cao cấp chuyển nó vào nhánh Dev để được lưu trữ cuối cùng trong một môi trường qa để được nhìn qua vào cuối của chạy nước rút.