2011-02-22 36 views
12

Tôi hiểu rằng chiến lược hợp nhất "của chúng ta" (nghe báo giá xung quanh hợp nhất?) Thực sự không sử dụng bất kỳ cam kết nào từ chi nhánh khác.Tại sao một người sử dụng "git merge -s ours"?

Chiến lược "của chúng ta" đôi khi được đề cập là "giữ lịch sử của người khác". Nhưng nó ghi lại lịch sử đó là "áp dụng". Kỳ dị. Có trường hợp nào tôi muốn hành vi này không?

Thay vào đó, bạn cũng có thể nhập chi nhánh khác và để lịch sử ở đó, nơi nó thuộc về.

Lưu ý rằng tôi hỏi về chiến lược "-s của chúng tôi", không phải tùy chọn "-X của chúng tôi" để "-s đệ quy" (khác biệt ở chỗ nó áp dụng những cam kết không xung đột).

+0

Mặc dù rất muộn: Có một cái nhìn [ở đây] (http://stackoverflow.com/a/1426163/5784831) – Christoph

Trả lời

10

Một sử dụng là để "bỏ qua" một cam kết được thực hiện trên một chi nhánh bảo trì mà không có ý định đi trở lại nhánh phát triển chính/thân cây của bạn. Xem câu hỏi trước này để biết ví dụ: git - skipping specific commits when merging

2

Tôi đang sử dụng kết hợp giả này trong một nhánh bổ sung được sử dụng để theo dõi các nhánh khác, kể cả các nhánh bị bỏ rơi. Chi nhánh bổ sung này chỉ có một tệp (gọi là branches-list), chứa một danh sách văn bản của các nhánh hoạt động và không hoạt động, nhưng tại các điểm quan trọng (chủ yếu là các nhánh và "cuối nhánh", hoặc hợp nhất hoặc bỏ) các chi nhánh phát triển được sáp nhập (với "-s chúng ta") cho chi nhánh này.

Dưới đây là một ảnh chụp màn hình gần đây của our project:

screenshot

Do đó, tôi cuối cùng nhánh elo-test từ thạc sĩ, và sau đó từ này tôi nhánh stroke-transform-example cho question here của tôi (và câu trả lời - điều này cần phải có được hai khác nhau cam kết, mặc dù). Tại mỗi điểm chi nhánh, và quan trọng hơn, tại mỗi điểm khi nhánh kết thúc mà không được sáp nhập vào một nhánh khác (sẽ xảy ra với stroke-transform-example khi tôi dọn dẹp tiếp theo), bây giờ tôi hợp nhất nhánh này với -s ours đến meta- chi nhánh branches.

Sau đó, sau này tôi có thể xóa các nhánh không được sử dụng nữa mà không làm mất lịch sử của chúng, vì vậy đầu ra của git branch -a luôn luôn là khá nhỏ. Nếu sau đó tôi muốn xem lại những gì tôi đã làm thì tôi có thể dễ dàng tìm thấy chúng.

(Tôi nghĩ rằng đây không phải là thực sự những gì tùy chọn này được thực hiện cho, nhưng nó hoạt động khá tốt đẹp.)

+0

Cảm ơn bạn cho câu trả lời minh họa của bạn. Sau khi * hợp nhất -sours ", phân biệt này" giả "hợp nhất từ" sáp nhập thực sự "đòi hỏi phải nhìn vào sự khác biệt, tôi nhận được quyền này? –

+0

btw & ot, tôi nghĩ tôi sẽ thử [link] này (http: //www.fencing) -game.de/en/rules) thỉnh thoảng (với giấy và bút chì) –

+1

Có, bạn nói đúng, trong trường hợp của tôi, tôi chỉ sử dụng các kết hợp giả này trên nhánh 'branch', vì vậy nó rất dễ nhìn thấy. trò chơi dễ chơi hơn nhiều với hỗ trợ máy tính, vì bạn không nên xem các điểm ẩn của contrahent của bạn. Hãy xem chương trình của chúng tôi, bạn có thể chơi trực tuyến miễn phí :-) –

0

Một cách sử dụng khác là thay thế cho lực đẩy không gây ra thay đổi không nhanh về phía trước cho người khác.

Ví dụ: bạn muốn hoàn nguyên cam kết đến (ngu ngốc), nhưng bạn không muốn làm git push -f vì sau đó bạn sẽ dành nửa giờ tiếp theo hướng dẫn khách hàng của bạn thông qua khôi phục từ đó và bạn muốn thay thế ngắn hơn thành

git checkout -b temp remote/origin 
git revert HEAD 
git push temp:origin 
git checkout master 
git merge origin/master 

vì vậy bạn chỉ cần làm

git merge -s ours origin/master 
1

một lý do khác là khi bạn có một chi nhánh đó là rất không đồng bộ với chi nhánh hoạt động của bạn, và bạn muốn cập nhật những cái cũ bằng một hoạt động, nhưng có thể xung đột nhập ngăn không cho việc này được thực hiện dễ dàng với việc hợp nhất thông thường.

Ví dụ, trường hợp sử dụng của tôi là:

Bạn có một bậc thầy và dev chi nhánh, và đối với một số lý do nào, bạn chưa được cập nhật chi nhánh chủ của bạn trong tuần, và cố gắng của bạn để sáp nhập chi nhánh dev của bạn vào tổng thể hiện nay dẫn đến xung đột hợp nhất. Những gì bạn có thể muốn làm là ghi đè lên nhánh chính của bạn với trạng thái hiện tại của nhánh dev của bạn, vì vậy hãy mang chúng cùng đồng bộ.

Việc bạn có thể thực hiện trong trường hợp này là như sau, sử dụng các bước do người dùng SO khác nêu ra in another SO answer here. Nhưng vui lòng xem ghi chú cảnh báo của tôi bên dưới.

git checkout dev 
git merge -s ours master 
git checkout master 
git merge dev 

Đáng lưu ý: Cuối cùng, chủ nhân của tôi đã cập nhật với dev của tôi, nhưng dev cho thấy 4 cam kết được đẩy lên điều khiển xa, điều này thật lạ. Nên có 0 để đẩy, vì tôi chỉ muốn cập nhật chủ. Tuy nhiên, mã có vẻ tốt. Chỉ cần đáng chú ý, vì tôi chưa bao giờ sử dụng git merge -s ours bản thân mình trước khi điều này vì vậy im không 100% về cách sử dụng của nó.

Tôi cũng tìm thấy một câu trả lời bằng ours có thể hữu ích với mọi người: https://stackoverflow.com/a/13307342/339803

Các vấn đề liên quan