Có phiên bản nào của họ không, phiên bản của họ có thể được sử dụng hay không?

Khi hợp nhất nhánh chủ đề "B" thành "A" bằng cách sử dụng git merge, tôi gặp một số xung đột. Tôi biết tất cả các xung đột có thể được giải quyết bằng phiên bản trong "B".

Tôi nhận thức được git merge -s ours. Nhưng những gì tôi muốn là một cái gì đó như git merge -s theirs.

Tại sao nó không tồn tại? Làm thế nào tôi có thể đạt được kết quả tương tự sau khi hợp nhất xung đột với các gitlệnh hiện có ? ( git checkoutmọi tệp không được trộn từ B)

CẬP NHẬT: "Giải pháp" chỉ loại bỏ bất cứ thứ gì từ nhánh A (điểm cam kết hợp nhất thành phiên bản B của cây) không phải là thứ tôi đang tìm kiếm.

Thêm -Xtùy chọn vào theirs. Ví dụ:

git checkout branchA
git merge -X theirs branchB

Mọi thứ sẽ hợp nhất theo cách mong muốn.

Điều duy nhất tôi thấy có vấn đề là nếu các tệp bị xóa khỏi nhánhB. Chúng hiển thị như xung đột nếu một cái gì đó khác ngoài git đã loại bỏ.

Việc khắc phục rất dễ dàng. Chỉ cần chạy git rmvới tên của bất kỳ tập tin đã bị xóa:

git rm {DELETED-FILE-NAME}

Sau đó, -X theirsnên làm việc như mong đợi.

Tất nhiên, thực hiện loại bỏ thực tế bằng git rmlệnh sẽ ngăn xung đột xảy ra ngay từ đầu.

Lưu ý : Một tùy chọn hình thức dài hơn cũng tồn tại.

Để sử dụng nó, thay thế:

-X theirs

với:

--strategy-option=theirs

Một giải pháp khả thi và đã được thử nghiệm để sáp nhập chi nhánhB vào chi nhánh đã thanh toán của chúng tôiA:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

Để tự động hóa nó, bạn có thể gói nó thành một tập lệnh bằng cách sử dụng BranchA và BranchB làm đối số.

Giải pháp này bảo tồn cha mẹ thứ nhất và thứ hai của cam kết hợp nhất, như bạn mong đợi git merge -s theirs branchB.

Các phiên bản cũ hơn của git cho phép bạn sử dụng chiến lược hợp nhất "của họ":

git pull --strategy=theirs remote_branch

Nhưng điều này đã bị xóa, như được giải thích trong tin nhắn này của Junio ​​Hamano (người duy trì Git). Như đã lưu ý trong liên kết, thay vào đó bạn sẽ làm điều này:

git fetch origin
git reset --hard origin

Mặc dù vậy, hãy coi chừng rằng điều này khác với hợp nhất thực tế. Giải pháp của bạn có lẽ là lựa chọn bạn thực sự tìm kiếm.

Nó không hoàn toàn rõ ràng kết quả mong muốn của bạn là gì, vì vậy có một số nhầm lẫn về cách làm "chính xác" trong câu trả lời và nhận xét của họ. Tôi cố gắng đưa ra một cái nhìn tổng quan và xem ba tùy chọn sau:

Hãy thử hợp nhất và sử dụng B cho các xung đột

Đây không phải là "phiên bản của họ cho git merge -s ours" mà là "phiên bản của họ cho git merge -X ours" (viết tắt của git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

Đây là những gì ví dụ câu trả lời của Alan W. Smith .

Chỉ sử dụng nội dung từ B

Điều này tạo ra một cam kết hợp nhất cho cả hai nhánh nhưng loại bỏ tất cả các thay đổi từ branchAvà chỉ giữ nội dung từ đó branchB.

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

Lưu ý rằng hợp nhất cam kết cha mẹ đầu tiên bây giờ là từ branchBvà chỉ thứ hai là từ branchA. Đây là những gì ví dụ như câu trả lời của Gandalf458 .

Chỉ sử dụng nội dung từ B và giữ đúng thứ tự cha mẹ

Đây là "phiên bản của họ" thực sự git merge -s ours. Nó có cùng nội dung như trong tùy chọn trước đó (nghĩa là chỉ từ branchB) nhưng thứ tự của cha mẹ là chính xác, tức là cha mẹ đầu tiên đến từ branchAvà thứ hai từ branchB.

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

Đây là những gì câu trả lời của Paul Pladijs (không yêu cầu một chi nhánh tạm thời).

Tôi đã sử dụng câu trả lời từ Paul Pladijs kể từ bây giờ. Tôi phát hiện ra, bạn có thể thực hiện hợp nhất "bình thường", xung đột xảy ra, vì vậy bạn làm

git checkout --theirs <file>

để giải quyết xung đột bằng cách sử dụng bản sửa đổi từ chi nhánh khác. Nếu bạn làm điều này cho mỗi tệp, bạn có hành vi giống như bạn mong đợi từ

git merge <branch> -s theirs

Dù sao, nỗ lực là nhiều hơn so với chiến lược hợp nhất! (Điều này đã được thử nghiệm với phiên bản git 1.8.0)

Tôi đã giải quyết vấn đề của mình bằng cách sử dụng

git checkout -m old
git checkout -b new B
git merge -s ours old

Khi hợp nhất nhánh chủ đề "B" trong "A" bằng cách sử dụng git merge, tôi gặp một số xung đột. Tôi> biết tất cả các xung đột có thể được giải quyết bằng phiên bản trong "B".

Tôi nhận thức được git merge -s của chúng tôi. Nhưng những gì tôi muốn là một cái gì đó như git merge> -s của họ.

Tôi giả sử rằng bạn đã tạo một nhánh của chủ và bây giờ muốn hợp nhất trở lại thành chủ, ghi đè lên bất kỳ nội dung cũ nào trong chủ. Đó chính xác là những gì tôi muốn làm khi tôi đi qua bài viết này.

Làm chính xác những gì bạn muốn làm, ngoại trừ hợp nhất một nhánh vào nhánh khác trước. Tôi chỉ làm điều này, và nó đã làm việc tuyệt vời.

git checkout Branch
git merge master -s ours

Sau đó, kiểm tra tổng thể và hợp nhất chi nhánh của bạn trong đó (nó sẽ diễn ra suôn sẻ ngay bây giờ):

git checkout master
git merge Branch

Nếu bạn ở chi nhánh A, hãy làm:

git merge -s recursive -X theirs B

Đã thử nghiệm trên phiên bản git 1.7.8

Để thực sự hợp nhất, chỉ lấy đầu vào từ nhánh bạn đang hợp nhất, bạn có thể thực hiện

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

Sẽ không có xung đột trong bất kỳ kịch bản nào tôi biết, bạn không phải tạo thêm các nhánh và nó hoạt động như một cam kết hợp nhất thông thường.

Điều này không chơi tốt với mô hình con tuy nhiên.

Tại sao nó không tồn tại?

Trong khi tôi đề cập đến trong " lệnh git để tạo một nhánh giống như một nhánh khác " git merge -s theirs, hãy lưu ý rằng Git 2.15 (Q4 2017) hiện rõ ràng hơn:

Tài liệu về ' -X<option>' cho các sự hợp nhất đã được viết sai để đề xuất rằng " -s theirs" tồn tại, đó không phải là trường hợp.

Xem cam kết c25d98b (ngày 25 tháng 9 năm 2017) của Junio ​​C Hamano ( gitster) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 4da3e23 , ngày 28 tháng 9 năm 2017)}

chiến lược hợp nhất: tránh ngụ ý rằng " -s theirs" tồn tại

Mô tả về -Xourstùy chọn hợp nhất có một ghi chú chính xác cho độc giả biết rằng nó rất khác so -s oursvới chính xác, nhưng mô tả về -Xtheirsnó theo sau nó vô tư nói "điều này ngược lại ours", tạo ấn tượng sai mà người đọc cũng cần được cảnh báo rằng nó rất khác với-s theirs , trong thực tế thậm chí không tồn tại.

-Xtheirslà một lựa chọn chiến lược được áp dụng cho chiến lược đệ quy. Điều này có nghĩa là chiến lược đệ quy vẫn sẽ hợp nhất mọi thứ có thể và sẽ chỉ quay lại theirslogic "" trong trường hợp có xung đột.

Cuộc tranh luận về sự liên quan hay không của một theirschiến lược hợp nhất đã được đưa trở lại gần đây trong chủ đề tháng 9 năm 2017 này .
Nó thừa nhận chủ đề cũ hơn (2008)

Nói tóm lại, cuộc thảo luận trước đây có thể được tóm tắt thành "chúng tôi không muốn -s theirs" vì nó khuyến khích quy trình làm việc sai ".

Nó đề cập đến bí danh:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Yaroslav Halchenko cố gắng ủng hộ một lần nữa cho chiến lược đó, nhưng Junio ​​C. Hamano nói thêm :

Lý do tại sao chúng ta và của họ không đối xứng là vì bạn là bạn chứ không phải họ --- sự kiểm soát và quyền sở hữu lịch sử của chúng tôi và lịch sử của họ không đối xứng.

Khi bạn quyết định rằng lịch sử của họ là dòng chính, bạn muốn coi dòng phát triển của mình là nhánh phụ và hợp nhất theo hướng đó, tức là cha mẹ đầu tiên của hợp nhất kết quả là một cam kết về lịch sử của họ và thứ hai cha mẹ là người xấu cuối cùng trong lịch sử của bạn. Vì vậy, bạn sẽ kết thúc bằng cách sử dụng "checkout their-history && merge -s ours your-history " để giữ cho việc làm cha mẹ đầu tiên hợp lý.

Và tại thời điểm đó, việc sử dụng " -s ours" không còn là cách giải quyết cho việc thiếu " -s theirs".
Nó là một phần thích hợp của ngữ nghĩa mong muốn, tức là từ quan điểm của dòng lịch sử kinh điển còn sót lại, bạn muốn bảo tồn những gì nó đã làm, vô hiệu hóa những gì dòng khác của lịch sử đã làm .

Junio ​​cho biết thêm, như nhận xét của Mike Beaton :

git merge -s ours <their-ref>nói một cách hiệu quả, "các cam kết được tạo ra <their-ref>trên chi nhánh của họ là các cam kết sẽ bị bỏ qua vĩnh viễn";
và điều này quan trọng bởi vì, nếu sau đó bạn hợp nhất từ ​​các tiểu bang sau này của chi nhánh của họ, những thay đổi sau này sẽ được đưa vào mà không có những thay đổi bị bỏ qua từng được đưa vào .

Xem câu trả lời được trích dẫn rộng rãi của Junio ​​Hamano : nếu bạn sẽ loại bỏ nội dung đã cam kết, chỉ cần loại bỏ các cam kết hoặc bằng bất cứ giá nào, hãy để nó ra khỏi lịch sử chính. Tại sao mọi người trong tương lai đọc các thông điệp cam kết từ các cam kết không có gì để cung cấp?

Nhưng đôi khi có những yêu cầu hành chính, hoặc có lẽ một số lý do khác. Đối với những tình huống mà bạn thực sự phải ghi lại các cam kết không đóng góp gì, bạn muốn:

(chỉnh sửa: wow, tôi đã quản lý để có được lỗi này trước đây. Cái này hoạt động.)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Cái này sử dụng lệnh đọc cây git, nhưng làm cho tổng thể công việc ngắn hơn.

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Điều này sẽ hợp nhất newBranch của bạn trong baseBranch hiện có

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Tôi nghĩ những gì bạn thực sự muốn là:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

Điều này có vẻ vụng về, nhưng nó nên làm việc. Suy nghĩ duy nhất tôi thực sự không thích về giải pháp này là lịch sử git sẽ gây nhầm lẫn ... Nhưng ít nhất lịch sử sẽ được bảo tồn hoàn toàn và bạn sẽ không cần phải làm gì đặc biệt cho các tệp bị xóa.

Tương đương (giữ trật tự cha mẹ) để 'git merge -s nhánh của họB'

Trước khi hợp nhất:

!!! Hãy chắc chắn rằng bạn đang ở trong trạng thái sạch sẽ !!!

Thực hiện hợp nhất:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

Những gì chúng ta đã làm ? Chúng tôi đã tạo một cam kết mới mà hai cha mẹ của chúng tôi và của họ và mạng lưới của cam kết là chi nhánhB - của họ

Sau khi hợp nhất:

Chính xác hơn:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Câu trả lời này được đưa ra bởi Paul Pladijs. Tôi chỉ nhận lệnh của anh ấy và tạo một bí danh git cho thuận tiện.

Chỉnh sửa .gitconfig của bạn và thêm vào như sau:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

Sau đó, bạn có thể "git merge -s thems A" bằng cách chạy:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Gần đây tôi chỉ cần làm điều này cho hai kho riêng biệt có chung lịch sử. Tôi bắt đầu với:

• Org/repository1 master
• Org/repository2 master

Tôi muốn tất cả các thay đổi repository2 masterđược áp dụng repository1 master, chấp nhận tất cả các thay đổi mà repository2 sẽ thực hiện. Theo thuật ngữ của git, đây phải là một chiến lược gọi là -s theirsNHƯNG nó không tồn tại. Hãy cẩn thận vì -X theirsđược đặt tên như nó sẽ là những gì bạn muốn, nhưng nó không giống nhau (thậm chí nó còn nói như vậy trong trang man).

Cách tôi giải quyết điều này là đi đến repository2và tạo một chi nhánh mới repo1-merge. Trong chi nhánh đó, tôi đã chạy git pull git@gitlab.com:Org/repository1 -s oursvà nó hợp nhất không có vấn đề gì. Sau đó tôi đẩy nó ra xa.

Sau đó tôi trở lại repository1và làm một chi nhánh mới repo2-merge. Trong nhánh đó, tôi chạy git pull git@gitlab.com:Org/repository2 repo1-mergesẽ hoàn thành với các vấn đề.

Cuối cùng, bạn sẽ cần phải đưa ra một yêu cầu hợp nhất repository1để biến nó thành chủ mới, hoặc chỉ giữ nó như một nhánh.

Một cách đơn giản và trực quan (theo tôi) cách làm hai bước là

git checkout branchB .
git commit -m "Picked up the content from branchB"

theo dõi bởi

git merge -s ours branchB

(đánh dấu hai nhánh là hợp nhất)

Nhược điểm duy nhất là nó không xóa các tệp đã bị xóa trong nhánhB khỏi nhánh hiện tại của bạn. Một khác biệt đơn giản giữa hai nhánh sau đó sẽ hiển thị nếu có bất kỳ tệp nào như vậy.

Cách tiếp cận này cũng làm cho nó rõ ràng từ nhật ký sửa đổi sau đó những gì đã được thực hiện - và những gì đã được dự định.