2014-07-23 19 views
6

Tôi bắt đầu làm việc trên chi nhánh chính. Gần một năm trước, tôi đã tạo một chi nhánh khác dev mà tôi đã thực hiện một số thay đổi. Từ đó tôi tiếp tục làm việc trên nhánh dev. Bây giờ tôi muốn hợp nhất dev thành master, dẫn đến nhiều xung đột. Tôi muốn hợp nhất dev thành master bằng cách ghi đè nội dung của chi nhánh chính tức là đối với bất kỳ xung đột nào nảy sinh tôi muốn giữ phiên bản mã của chi nhánh dev. Nó được hoàn thiện bằng cách nào ?git Làm cách nào để hợp nhất chi nhánh vào nhánh chính bằng cách ghi đè hoàn toàn chi nhánh chính

Trả lời

5

Bạn sẽ muốn sử dụng một "hợp nhất sử dụng của họ" chiến lược, được thiết lập bằng cách sử dụng -X cờ

git checkout master 
git merge -X theirs dev 
5

Bạn có thể chỉ định the strategy option với -X switch:

git checkout master 
git merge -X theirs dev 

Một chút giải trình. Các -X theirs có nghĩa là: Sử dụng chiến lược đệ quy với hợp nhất nhưng dự phòng của họ thay đổi nếu chiến lược không thể giải quyết xung đột.

Điều này khác với -s ours (vì một lý do nào đó không có -s theirs) sẽ là một tham số tham gia giải pháp của chúng tôi luôn là đối với các xung đột.

git-merge(1) Phần Chiến lược hợp nhất cung cấp giải thích sâu hơn về điều này.

+0

-X là gì? –

+0

@hrehman tùy chọn chiến lược. Đã thêm liên kết để tham khảo thêm. –

+0

Hãy cẩn thận ở đây, '-X ours' hoặc' -X theirs' khá khác với '-s ours'. Không có '-s của họ'. Có vẻ như '-X của họ 'là những gì OP muốn vì vậy tôi tin rằng đây là câu trả lời đúng (và upvoting nó). – torek

2

Bạn có thể buộc một push thành bậc thầy với tất cả các cam kết của bạn

git push -f origin master 
1

Như Paulo Bu noted, git cung cấp phương pháp khác nhau cho điều này khi bạn muốn có một hợp nhất với một cách tiếp cận "của chúng ta", nhưng chỉ có một "out of the hộp "khi bạn muốn kết hợp với cách tiếp cận" của họ ". Nó có giá trị minh họa hai bằng ví dụ:

$ git merge -s ours deadbranch # merge deadbranch and ignore all its code 

hay:

$ git merge -X ours livebranch # merge livebranch but use ours when conflicting 

Hãy để tôi cũng lưu ý ở đây là khi bạn sử dụng git merge, git đầu tiên tìm thấy những "hợp nhất cơ sở", điểm mà tại đó hai chi nhánh là cuối cùng trong đồng bộ:

  o - X <-- master 
     /
o - o - B 
      \ 
      o - Y <-- otherbranch 

đây B đại diện cho cam kết đó là merge-base, X là đỉnh của chi nhánh của bạn (master) và Y là đầu của nhánh khác. Những gì git sẽ làm là diff B vs XB vs Y.

Giả sử trong nhánh "của chúng tôi", master, chúng tôi có các tệp unchanged, no-conflicts, và removed. Những cái tên này liên quan đến những gì đã xảy ra ở hai nhánh còn lại.

file unchanged là không thay đổi trong chi nhánh to-be-sáp nhập (có nghĩa là, các diff B-Y thấy gì cả cho file unchanged). git merge không bao giờ chạm vào nó, vì vậy không có gì thay đổi bất kể đối số chúng tôi đưa ra cho git merge.

Các tệp khác có một số thay đổi trong master và/hoặc chi nhánh khác.

Tệp no-conflicts có một thay đổi trong số master ở trên cùng và một thay đổi ở chi nhánh khác ở dưới cùng. Hai thay đổi này không xung đột. git merge -s recursive sẽ kết hợp các thay đổi, cho dù bạn có sử dụng tùy chọn -X ours hay không. Tuy nhiên, git merge -s ours sẽ hủy thay đổi của chúng, giữ phiên bản tệp no-conflicts của chúng tôi. Đối với trường hợp này, kết quả là khác nhau.

Tệp có một thay đổi trong chương trình chính ở đầu tệp và thay đổi khác trong nhánh khác cũng ở trên cùng. (Những thay đổi có thể ở bất kỳ đâu, chúng chỉ cần chồng lên nhau. "Ở trên cùng" làm cho nó trùng lặp.) Điều đó có nghĩa là những thay đổi này xung đột. Sử dụng git merge -s recursive, bạn sẽ nhận được đơn khiếu nại và phải giải quyết xung đột. Thêm -X ours và git sẽ thực hiện thay đổi của bạn, vứt bỏ thay đổi của họ. Sử dụng git merge -s ours, git sẽ thực hiện thay đổi của bạn và vứt bỏ thay đổi — vì vậy đối với trường hợp này là, kết quả là như nhau.

Tệp removed không thay đổi trong master nhưng bị xóa ở chi nhánh khác. Trong trường hợp này, git merge -s recursive sẽ xóa tệp, cho dù bạn có sử dụng -X ours hay không. Tuy nhiên, git merge -s ours sẽ bỏ qua việc xóa.

Nói tóm lại, sự khác biệt giữa -s ours-s recursive -X ours là với cựu, git hoàn toàn bỏ qua các diff B-Y; sau đó, git cố gắng kết hợp các khác biệt B -to- X (của chúng ta) và B -to- Y (của chúng), nhưng trong trường hợp có xung đột khi kết hợp, nó sẽ chọn thay đổi B -to- X.

Với -X theirs (mà thực sự là -s recursive -X theirs), nỗ lực git để kết hợp các diffs, và trong trường hợp xung đột, chọn sự thay đổi B -to- Y qua sự thay đổi B -to- X.


Nó có thể đạt được tương đương với -s theirs mặc dù git không có này được xây dựng trong. Để làm điều này, sử dụng git merge --no-commit otherbranch, sau đó git rm -rf . từ cấp cao nhất để loại bỏ các hợp nhất kết quả (có hoặc không có xung đột) , sau đó git checkout otherbranch -- . từ cấp cao nhất để điền lại cây và chỉ mục dựa trên otherbranch. Sau đó, chỉ cần git commit kết quả. Nó khá hiếm khi muốn điều này, mặc dù, đó là lý do tại sao git không có nó như là một xây dựng trong chiến lược.

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