Hoàn nguyên cam kết hợp nhất git, sau đó hoàn nguyên hoàn nguyên

Question

Nhóm của chúng tôi sử dụng Github Pull Requests để quản lý quy trình làm việc của chúng tôi, giống như what is described here. Khi xem xét thủ công yêu cầu kéo được chấp nhận, đôi khi chúng tôi cần hoàn nguyên quá trình hợp nhất đó vì nó chưa sẵn sàng để triển khai cho các máy chủ sản xuất của chúng tôi.

Tuy nhiên, nếu nhà phát triển cố gắng đưa ra Yêu cầu kéo lần nữa, nó không nhận ra những thay đổi này đã được hoàn nguyên và thấy rằng các cam kết đã có trong nhánh chính. Nó sẽ chỉ bao gồm các cam kết gần đây của họ kể từ khi hoàn nguyên, nhưng những gì chúng tôi thực sự muốn là giới thiệu lại TẤT CẢ các cam kết đã được hoàn nguyên, cộng với công việc mới của họ. Nói cách khác, chúng tôi thích cách để phát hành lại Yêu cầu kéo ban đầu.

Vì Github không hỗ trợ tính năng này (tức là, không hoàn nguyên hợp nhất, cũng như không hoàn tác/phát hành lại yêu cầu kéo ban đầu), tôi hiện đang hoàn nguyên quá trình hợp nhất được hoàn nguyên. Điều này cảm thấy sai.

Tôi có thể sử dụng những cách nào khác để đạt được cùng một mục tiêu trong git? (hoặc Github nếu có thể)

Answer 1

Tôi nghĩ rằng vấn đề của bạn ở đây phát sinh bởi vì khi bạn đang xử lý các yêu cầu kéo, bạn đang chọn tự động hợp nhất chúng trên GitHub. Trong ba cách được đề xuất để xử lý các yêu cầu kéo described in the documentation bạn đang sử dụng lệnh cuối cùng ("Tự động hợp nhất"), chỉ là recently implemented. Cá nhân, tôi nghĩ rằng điều này chỉ thích hợp cho các yêu cầu kéo nhỏ mà rõ ràng là chính xác. Đối với bất cứ điều gì phức tạp hơn, tôi muốn sử dụng phương pháp tiếp cận đầu tiên, tức là

• thêm kho của người yêu cầu như một mới từ xa
• lấy từ đó xa
• cố gắng hợp nhất
• kiểm tra cẩn thận
• đẩy kết quả nếu bạn hài lòng

Điều đó có nghĩa là phiên bản được hợp nhất chỉ công khai khi bạn đã thử nghiệm và quyết định o đẩy. Nếu bạn không muốn, bạn chỉ có thể đặt lại nhánh chính của bạn về vị trí trước đó của nó.

---

Như một vấn đề quan tâm, nó có thể là đáng nói thêm về những gì sẽ xảy ra nếu bạn làm cuối cùng phải trở lại một kết hợp đáng tiếc, nhưng vẫn muốn có tùy chọn để tái hợp nhất một phiên bản mới hơn của nhánh đó. Mặc dù nó có thể cảm thấy sai, vì tôi hiểu nó cách dễ nhất để đối phó với tình hình đó thực sự là để hoàn nguyên sự trở lại. Bạn có thể tìm thêm thảo luận về vấn đề này trong this post from the Pro Git blog và another discussion of the same problem bởi Linux Torvalds cũng có thể hữu ích.

Answer 2

Tôi khuyên các bạn nên thực hiện một cách tiếp cận khác. Luồng công việc của bạn về việc hoàn nguyên và hoàn nguyên trở lại có vẻ rất khó hiểu với tôi. Vấn đề thực tế bạn đang cố gắng giải quyết có thể được giải quyết khác nhau.

Tôi đề nghị bạn thay đổi quy trình làm việc của mình để sử dụng hai nhánh. Một nhánh ổn định (master) và một chi nhánh phát triển (develop). Tất cả công việc đi vào chi nhánh develop hoặc vào các nhánh chủ đề riêng biệt. Yêu cầu kéo luôn được gửi đến chi nhánh develop, sau đó hợp nhất thành develop khi được chấp thuận.

master ban đầu được phân nhánh là develop.Ngay sau khi develop ở trạng thái ổn định, bạn hợp nhất nó vào master. master là bản phát hành ổn định hiện tại.

Điều này được dựa trên số nvie's "A successful Git branching model".

Answer 3

Nếu bạn nhận được một trung đoàn chi nhánh cho mỗi tính năng, bạn có thể xây dựng lại một ứng cử viên phát hành với các tính năng bạn thích. Bạn sẽ không cần phải "trở lại một hợp nhất":

tiếp tục đọc: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Xin vui lòng xem các ý kiến ​​cũng cho cái nhìn sâu sắc thêm. Nó hoạt động thực sự tốt cho chúng tôi.