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
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
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.
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
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 X
và B
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
và -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.
- 1. Làm cách nào để hợp nhất phát triển chi nhánh thành chi nhánh chính trong SourceTree?
- 2. làm cho chi nhánh git chi nhánh chính
- 3. Cách thay thế nhánh chính bằng chi nhánh thí nghiệm
- 4. Cách ghi đè chi nhánh cụ thể bằng master
- 5. TFS: Ghi đè chi nhánh với một chi nhánh khác
- 6. chi nhánh git (không có chi nhánh)
- 7. hợp nhất với các chi nhánh, không quan trọng bạn hợp nhất vào chi nhánh nào?
- 8. Git: đặt lại/hoàn nguyên toàn bộ chi nhánh về trạng thái chi nhánh khác?
- 9. Cách hoàn nguyên chi nhánh chính về phía thượng nguồn
- 10. TFS: Hợp nhất trở lại chi nhánh chính
- 11. Git: Hợp nhất nhiều cam kết từ một chi nhánh này sang một chi nhánh khác
- 12. hợp nhất một chi nhánh địa phương vào một chi nhánh địa phương khác
- 13. Git: Hợp nhất để làm chủ khi tự động chọn ghi đè lên tệp chính với chi nhánh
- 14. "git pull" hoặc "git merge" giữa các nhánh chính và chi nhánh phát triển
- 15. ghi đè và đẩy một chi nhánh Git
- 16. Làm cách nào để hợp nhất nhánh gerrit với chi nhánh gerrit khác
- 17. Git Sáp nhập chi nhánh vào Master
- 18. Git - Chi nhánh chọn lọc
- 19. Thay thế chi nhánh địa phương với chi nhánh ở xa hoàn toàn
- 20. Hoàn nguyên việc hợp nhất chi nhánh xấu
- 21. Git danh sách chi nhánh sáp nhập vào một chi nhánh nhưng không phải vào một
- 22. Đóng băng chi nhánh Git
- 23. ngăn git hợp nhất thành nhánh chính
- 24. SVN chi nhánh của một chi nhánh
- 25. Tạo chi nhánh git dựa trên một chi nhánh khác
- 26. Git-Flow hoàn tác chi nhánh đã hoàn thành
- 27. Chi nhánh rebit Git với trẻ em đã hợp nhất
- 28. Luồng Git - tạo chi nhánh tính năng ngoài một chi nhánh khác
- 29. Git cam kết submodule chung (chi nhánh chính)
- 30. Hợp nhất (không có chi nhánh) vào tổng thể
-X là gì? –
@hrehman tùy chọn chiến lược. Đã thêm liên kết để tham khảo thêm. –
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