"git merge -s ours"의 "그들"버전이 있습니까?

을 사용하여 주제 분기 "B"를 "A"로 병합하면 git merge충돌이 발생합니다. "B"버전을 사용하여 모든 충돌을 해결할 수 있다는 것을 알고 있습니다.

알고 git merge -s ours있습니다. 그러나 내가 원하는 것은와 같습니다 git merge -s theirs.

왜 존재하지 않습니까? 기존 git명령 과의 병합 충돌 후에 어떻게 동일한 결과를 얻을 수 있습니까? ( git checkoutB에서 병합되지 않은 모든 파일)

업데이트 : 지점 A (병합 커밋 지점 B의 트리 버전)에서 아무것도 버리는 "솔루션"은 내가 찾고있는 것이 아닙니다.

에 -X옵션을 추가하십시오 theirs. 예를 들면 다음과 같습니다.

git checkout branchA
git merge -X theirs branchB

모든 것이 원하는 방식으로 병합됩니다.

내가 본 유일한 문제는 파일이 branchB에서 삭제 된 경우입니다. git 이외의 것이 제거를 수행하면 충돌로 나타납니다.

수정이 쉽습니다. git rm삭제 된 파일 이름으로 실행 하십시오.

git rm {DELETED-FILE-NAME}

그 후, -X theirs예상대로 작동합니다.

물론, git rm명령 을 사용하여 실제 제거를 수행 하면 처음부터 충돌이 발생하지 않습니다.

참고 : 더 긴 양식 옵션도 있습니다.

사용하려면 다음을 교체하십시오.

-X theirs

와:

--strategy-option=theirs

지점 B를 체크 아웃 한 지점 A에 병합하기위한 가능한 테스트 된 솔루션 :

# 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

이를 자동화하기 위해 branchA 및 branchB를 인수로 사용하여 스크립트로 랩핑 할 수 있습니다.

이 솔루션은 예상 한대로 병합 커밋의 첫 번째와 두 번째 부모를 유지합니다 git merge -s theirs branchB.

이전 버전의 git에서는 "그들의"병합 전략을 사용할 수있었습니다.

git pull --strategy=theirs remote_branch

그러나 Junio ​​Hamano (Git 관리자) 가이 메시지에서 설명한 대로이 기능 은 삭제되었습니다 . 링크에서 언급했듯이 대신 다음을 수행하십시오.

git fetch origin
git reset --hard origin

그러나 이것은 실제 병합과는 다릅니다. 귀하의 솔루션은 아마도 당신이 정말로 찾고있는 옵션 일 것입니다.

원하는 결과가 무엇인지 명확하게 알 수 없으므로 답변과 의견에 "올바른"방법을 사용하는 것에 대해 약간의 혼란이 있습니다. 개요를 제공하려고 시도하고 다음 세 가지 옵션을 봅니다.

병합을 시도하고 충돌에 B를 사용하십시오.

입니다 하지 은 "에 대한 그들의 버전 git merge -s ours"하지만 "에 대한 그들의 버전 git merge -X ours(대한 짧은" git merge -s recursive -X ours) :

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

예를 들어 Alan W. Smith의 답변 이 이에 해당합니다.

B의 컨텐츠 만 사용

이렇게하면 두 분기 모두에 대해 병합 커밋이 만들어 지지만의 모든 변경 사항은 버리고 branchA내용 만 유지됩니다 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

이제 첫 번째 상위 커밋 커밋은 from branchB이고 두 번째 만 from branchA입니다. 이것이 예를 들어 간달프 458의 답변 입니다.

B의 콘텐츠 만 사용하고 올바른 부모 순서를 유지하십시오.

이것은 "의 실제 버전 git merge -s ours"입니다. 이 같은 전에 옵션 등의 내용 (즉,에서, 즉에만있다 branchB)하지만를 부모의 순서가 올바른, 즉 최초의 부모로부터 온다 branchA과에서 두 번째 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

이것이 Paul Pladijs의 답변입니다 (임시 지점 필요 없음).

지금부터 Paul Pladijs의 답변을 사용했습니다. "정상"병합을 수행 할 수 있으며 충돌이 발생하므로

git checkout --theirs <file>

다른 지점의 개정판을 사용하여 충돌을 해결합니다. 각 파일에 대해이 작업을 수행하면 예상 한 것과 동일한 동작이 나타납니다.

git merge <branch> -s theirs

어쨌든 노력은 합병 전략보다 더 중요합니다! (이것은 자식 버전 1.8.0에서 테스트되었습니다)

나는 내 문제를 해결했다.

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

git merge를 사용하여 "A"의 주제 분기 "B"를 병합하면 충돌이 발생합니다. "B"버전을 사용하여 모든 충돌을 해결할 수 있음을 알고 있습니다.

git merge -s 우리를 알고 있습니다. 그러나 내가 원하는 것은 git merge> -s와 같은 것입니다.

마스터에서 브랜치를 생성하고 마스터로 다시 병합하여 마스터의 이전 항목을 재정의하려고한다고 가정합니다. 그것이 내가이 포스트를 만났을 때하고 싶었던 바로 그 것입니다.

한 지점을 다른 지점으로 먼저 병합하는 것을 제외하고는 원하는 작업을 정확하게 수행하십시오. 방금이 작업을 수행했으며 훌륭하게 작동했습니다.

git checkout Branch
git merge master -s ours

그런 다음 마스터를 체크 아웃하고 분기를 병합하십시오 (지금 원활하게 진행됨).

git checkout master
git merge Branch

지점 A에 있다면 :

git merge -s recursive -X theirs B

자식 버전 1.7.8에서 테스트

병합 하려는 브랜치의 입력 만 가져 오는 병합을 실제로 올바르게 수행하려면 할 수 있습니다

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

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

git commit --amend

내가 아는 시나리오에는 충돌이 없으며 추가 분기를 만들 필요가 없으며 일반적인 병합 커밋처럼 작동합니다.

그러나 이것은 서브 모듈과 잘 어울리지 않습니다.

왜 존재하지 않습니까?

" 하나의 브랜치를 다른 브랜치처럼 만들기위한 git 명령 "에서 시뮬레이트하는 방법에 대해 git merge -s theirs언급했지만 Git 2.15 (2017 년 4 분기)가 더 명확 해졌습니다.

-X<option>병합을 위한 ' '에 대한 문서 가 잘못되어 " -s theirs"이 (가) 존재하지 않는다고 제안되었습니다 .

참조 c25d98b 커밋 에 의해 (2017 9월 25일)를 Junio C 하마노 ( gitster) .
^{( Junio ​​C gitsterHamano 에 의해 병합 - 커밋 4da3e23 , 2017 년 9 월 28 일)}

병합 전략 : "-s theirs "가

-Xours병합 옵션에 대한 설명 에는 괄호 안에 메모와는 매우 다르며 -s ours, 그에 대한 설명은 정확하지만, 그에 대한 설명은 -Xtheirs부주의하게 "이것과 반대입니다 ours" 라고 말하면서 독자도 필요하다는 잘못된 인상을줍니다. -s theirs실제로 존재하지 않는 와는 매우 다르다는 경고를 받습니다.

-XtheirsA는 전략 옵션 재귀 전략에 적용했다. 이는 재귀 전략이 여전히 가능한 모든 것을 병합하고 theirs충돌시 " "논리 로만 넘어 간다는 것을 의미합니다 .

theirs병합 전략 의 적절성에 대한 논쟁은 최근 2017 년 9 월 스레드에서 다시 제기 되었습니다 . 오래된 (2008) 스레드를
인식 합니다.

간단히 말해서, 앞에서 논의한 내용은 " -s theirs잘못된 워크 플로를 장려하기 때문에 ' ' 원하지 않습니다 '라고 요약 할 수 있습니다 .

별명을 언급합니다.

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

야로슬라프 할 첸코 (Yaroslav Halchenko)는이 전략을 다시 한 번지지하려고 하지만 Junio ​​C. Hamano는 다음과 같이 덧붙입니다 .

우리와 그들의 것이 대칭이 아닌 이유는 당신이 아니고 당신이 아니기 때문입니다 .-- 우리의 역사와 역사의 통제와 소유권은 대칭이 아닙니다.

히스토리가 메인 라인이라고 결정한 후에는 개발 라인을 사이드 브랜치로 취급하고 해당 방향으로 병합하려고합니다. 부모는 당신의 역사에서 마지막으로 나쁜 사람입니다. 그래서 당신은 "checkout their-history && merge -s ours your-history "를 하면 첫 번째 부모를 현명하게 유지할 수 있습니다.

그리고 그 시점에서 " -s ours"의 사용은 더 이상 " "이 없어도 해결 방법이 아닙니다 -s theirs.
그것은 원하는 의미론의 적절한 부분입니다. 즉, 살아남은 정식 히스토리 라인의 관점에서, 당신은 그것이 행한 것을 보존하고, 다른 히스토리 라인이 한 것을 무효로하고 싶습니다 .

Junio는 Mike Beaton이 다음 과 같이 덧붙입니다 .

git merge -s ours <their-ref>효과적으로는 ' <their-ref>지속적으로 무시되는 커밋으로 지점에서 이루어진 마크 커밋'이라고 말합니다 .
나중에 분기의 상태에서 병합하는 경우 무시 된 변경 사항이 적용되지 않고 이후 변경 사항이 적용되므로 중요 합니다.

참조 후니 오 하마노의 널리 인용 답변 . 커밋 된 컨텐츠를 버릴 경우 커밋을 버리거나 어떤 식 으로든 주요 히스토리에서 제외하십시오. 앞으로 읽을 모든 사람들이 제공 할 것이없는 커밋 메시지를 커밋하는 이유는 무엇입니까?

그러나 때로는 관리 요구 사항이나 다른 이유가있을 수 있습니다. 아무것도 기여하지 않는 커밋을 실제로 기록 해야하는 상황에서는 다음을 원합니다.

(편집 : 와우, 전에이 문제를 잘못 처리 했습니까?이 것이 효과가 있습니다.)

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

이것은 git plumbing 명령 read-tree를 사용하지만 전반적인 워크 플로우를 단축시킵니다.

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>

기존 baseBranch에 newBranch를 병합합니다

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

실제로 원하는 것은 다음과 같습니다.

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

이것은 서투른 것처럼 보이지만 작동해야합니다. 내가이 솔루션에 대해 정말로 싫어하는 유일한 생각은 git history가 혼란 스러울 것입니다 ...하지만 최소한 역사는 완전히 보존되므로 삭제 된 파일에 대해 특별한 작업을 수행 할 필요가 없습니다.

'git merge -s theirs branchB'에 해당하는 항목 (부모 순서 유지)

병합하기 전에 :

!!! 깨끗한 상태인지 확인하십시오 !!!

병합을 수행하십시오.

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

우리는 무엇을 했습니까? 우리는 두 부모와 우리와 그들의 커밋이 branchB 인 새로운 커밋을 만들었습니다.

병합 후 :

더 정확하게:

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

이 답변은 Paul Pladijs가 제공했습니다. 방금 그의 명령을 취하고 편의를 위해 자식 별칭을 만들었습니다.

.gitconfig를 편집하고 다음을 추가하십시오.

[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"

그런 다음 다음을 실행하여 "git merge -s theirs A"를 실행할 수 있습니다.

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

나는 최근에 공통의 역사를 공유하는 두 개의 별도 저장소에 대해이 작업을 수행해야했습니다. 나는 시작했다 :

• Org/repository1 master
• Org/repository2 master

모든 변경 사항 repository2 master이에 적용 되기를 원했고 repository1 master, repository2가 수행 한 모든 변경 사항을 승인했습니다. git의 관점에서 볼 때 이것은 존재하지 않는 전략 이어야-s theirs 합니다. 때문에 조심 -X theirs당신이 원하는 것이 그것 같이 이름 만이 NOT 같은 (심지어 사람의 페이지에서 이렇게 말한다).

내가 이것을 해결 한 방법은 가서 repository2새로운 지사를 만드는 것이었다 repo1-merge. 그 지점에서 나는 달렸고 git pull git@gitlab.com:Org/repository1 -s ours아무런 문제없이 잘 병합되었습니다. 그런 다음 리모컨으로 밀어 넣습니다.

그런 다음 돌아가서 repository1새 지점을 repo2-merge만듭니다. 해당 지점에서 git pull git@gitlab.com:Org/repository2 repo1-merge문제가 완료됩니다.

마지막으로, 병합 요청을 발행 repository1하여 새 마스터로 만들거나 분기로 유지해야합니다.

간단하고 직관적 인 (제 생각에는) 2 단계 방법입니다.

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

뒤에

git merge -s ours branchB

(두 지점이 병합 된 것으로 표시)

유일한 단점은 현재 브랜치에서 branchB에서 삭제 된 파일을 제거하지 않는다는 것입니다. 그런 다음 두 가지 사이의 간단한 차이점은 그러한 파일이 있는지 보여줍니다.

이 접근 방식은 이후에 수행 된 작업과 수행 된 작업을 개정 로그에서 명확하게합니다.