Program Tip

git-merge --dry-run 옵션이 있습니까?

programtip 2020. 9. 30. 11:22
반응형

git-merge --dry-run 옵션이 있습니까?


충돌이 많은 원격 지점에서 병합하고 있습니다. 충돌 여부를 어떻게 알 수 있습니까?

--dry-runon 과 같은 것은 보이지 않습니다 git-merge.


이전에 언급했듯이 --no-commit플래그를 전달 하되 빨리 감기 커밋을 방지하려면 다음 --no-ff과 같이 전달하십시오 .

$ git merge --no-commit --no-ff $BRANCH

단계적 변경을 조사하려면 다음을 수행하십시오.

$ git diff --cached

빨리 감기 병합 인 경우에도 병합을 취소 할 수 있습니다.

$ git merge --abort

리포지토리와 원격지 간의 충돌을 자동으로 찾는 방법을 구현해야했습니다. 이 솔루션은 메모리에서 병합을 수행하므로 인덱스 나 작업 트리를 건드리지 않습니다. 이 문제를 해결할 수있는 가장 안전한 방법이라고 생각합니다. 작동 방식은 다음과 같습니다.

  1. 원격을 저장소로 가져옵니다. 예를 들면 :git fetch origin master
  2. git merge-base 실행 : git merge-base FETCH_HEAD master
  3. git merge-tree 실행 : git merge-tree mergebase master FETCH_HEAD( mergebase 는 이전 단계에서 merge-base가 인쇄 한 16 진수 ID입니다)

이제 원격 마스터를 로컬 마스터와 병합하려고하지만 모든 분기를 사용할 수 있다고 가정합니다. git merge-tree메모리에서 병합을 실행하고 결과를 표준 출력으로 인쇄합니다. 패턴 <<또는 >>. 또는 출력을 파일로 인쇄하고 확인할 수 있습니다. '둘 다에서 변경됨'으로 시작하는 줄을 찾으면 대부분 충돌이있을 것입니다.


이에 대한 내 간단한 무차별 대입 솔루션은 다음과 같습니다.

  1. "사전 마스터"분기 만들기 (물론 마스터에서)

  2. 이 사전 마스터에 원하는 모든 것을 병합하십시오.
    그러면 마스터를 건드리지 않고 어떻게 병합되었는지 볼 수 있습니다.

    • 사전 마스터를 마스터에 병합 또는
    • Wannabe에서 출시 된 모든 브랜치를 마스터로 병합

어쨌든 @ orange80의 조언을 따를 것입니다.


git과의 병합을 취소하는 것은 너무 쉬워서 드라 이런에 대해 걱정할 필요가 없습니다.

$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world

편집 : 아래 주석에서 언급했듯이 작업 디렉토리 나 스테이징 영역에 변경 사항이있는 경우 위 작업을 수행하기 전에 숨길 수 있습니다 (그렇지 않으면 위의 내용이 사라집니다 git reset).


이 작업에 대한 별칭을 만들고 매력처럼 작동합니다.

 git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '

이제 난 그냥 전화 해

git mergetest <branchname>

충돌이 있는지 확인합니다.


현재 분기를 원격 분기와 비교하면 풀 / 병합을 수행 할 때 변경 될 내용이 표시됩니다.

#see diff between current master and remote branch
git diff master origin/master

이를 위해 request-pull git 명령을 사용합니다 . 병합 할 때 발생하는 모든 변경 사항을 볼 수 있지만 로컬 또는 원격 저장소에서 아무것도하지 않아도 됩니다.

예를 들어 "feature-x"라는 브랜치를 마스터 브랜치에 병합하려고한다고 가정 해 보겠습니다.

git request-pull master origin feature-x

(아무것도하지 않고) 일어날 일에 대한 요약을 보여줍니다.

The following changes since commit fc01dde318:
    Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
    http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
    Adding some layout
    Refactoring
ioserver.js            |   8 +++---
package.json           |   7 +++++-
server.js              |   4 +--
layout/ldkdsd.js       | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js

-p매개 변수 를 추가하면 변경된 모든 파일에 대해 git diff를 수행하는 것처럼 전체 패치 텍스트도 얻을 수 있습니다.


아무도 아직 패치 사용을 제안하지 않은 것에 놀랐습니다.

에서 your_branch병합을 테스트하고 싶다고 master가정 해 보겠습니다 ( master체크 아웃 했다고 가정합니다 ).

$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch

그게 트릭을해야합니다.

다음과 같은 오류가 발생하면

error: patch failed: test.txt:1
error: test.txt: patch does not apply

that means that the patch wasn't successful and a merge would produce conflicts. No output means the patch is clean and you'd be able to easily merge the branch


Note that this will not actually change your working tree (aside from creating the patch file of course, but you can safely delete that afterwards). From the git-apply documentation:

--check
    Instead of applying the patch, see if the patch is applicable to the
    current working tree and/or the index file and detects errors. Turns
    off "apply".

Note to anyone who is smarter/more experienced with git than me: please do let me know if I'm wrong here and this method does show different behaviour than a regular merge. It seems strange that in the 8+ years that this question has existed noone would suggest this seemingly obvious solution.


This might be interesting: From the documentation:

If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.

But you could also do it the naive (but slow) way:

rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)

(Note: It won't work just cloning to /tmp, you'd need a copy, in order to be sure that uncommitted changes will not conflict).


I am aware that this is an old question, but it is the first to appear on a Google search.

Git introduced a --ff-only option when merging.

From: http://git-scm.com/docs/git-merge


--ff-only

Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.

Doing this will attempt to merge and fast-forward, and if it can't it aborts and prompts you that the fast-forward could not be performed, but leaves your working branch untouched. If it can fast-forward, then it will perform the merge on your working branch. This option is also available on git pull. Thus, you could do the following:

git pull --ff-only origin branchA #See if you can pull down and merge branchA

git merge --ff-only branchA branchB #See if you can merge branchA into branchB

I use git log to see what has changed on a feature branch from master branch

git log does_this_branch..contain_this_branch_changes

e.g. - to see what commits are in a feature branch that has/not been merged to master:

git log master..feature_branch

If you want to fast forward from B to A, then you must make sure that git log B..A shows you nothing, i.e. A has nothing that B doesn't have. But even if B..A has something, you might still be able to merge without conflicts, so the above shows two things: that there will be a fast-forward, and thus you won't get a conflict.


Make a temporary copy of your working copy, then merge into that, and diff the two.

참고URL : https://stackoverflow.com/questions/501407/is-there-a-git-merge-dry-run-option

반응형