git stash blunder : git stash pop은 병합 충돌로 끝났습니다.

git stash blunder : git stash pop은 병합 충돌로 끝났습니다.

---

나는 git stash pop병합 충돌로 끝났습니다. 파일 시스템에서 파일을 제거하고 git checkout아래와 같이 수행했지만 파일이 여전히 병합되지 않은 것으로 생각합니다. 그런 다음 파일을 바꾸고 git checkout다시 동일한 결과 를 시도했습니다 . 나는 -f깃발 로 그것을 강요하려고했습니다 . 도움을 주시면 감사하겠습니다!

chirag-patels-macbook-pro:haloror patelc75$ git status
app/views/layouts/_choose_patient.html.erb: needs merge
app/views/layouts/_links.html.erb: needs merge
# On branch prod-temp
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   db/schema.rb
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       unmerged:   app/views/layouts/_choose_patient.html.erb
#       unmerged:   app/views/layouts/_links.html.erb

chirag-patels-macbook-pro:haloror patelc75$ git checkout app/views/layouts/_choose_patient.html.erb
error: path 'app/views/layouts/_choose_patient.html.erb' is unmerged
chirag-patels-macbook-pro:haloror patelc75$ git checkout -f app/views/layouts/_choose_patient.html.erb
warning: path 'app/views/layouts/_choose_patient.html.erb' is unmerged

---

man git merge를 참조하십시오 ( 충돌 해결 방법 ) :

충돌을 본 후 두 가지 작업을 수행 할 수 있습니다.

• 병합하지 않기로 결정하십시오. 필요한 정리는 인덱스 파일을 HEAD 커밋으로 재설정하여 2를 반대로하고 2와 3으로 작성된 작업 트리 변경을 정리하는 것입니다. git-reset --hard를 사용할 수 있습니다.

• 충돌을 해결하십시오. 힘내 작업 트리에서 충돌을 표시합니다. 파일을 모양으로 편집하고 git을 색인에 추가하십시오. git commit을 사용하여 거래를 봉인하십시오.

그리고 TRUE MERGE 아래에서 (2와 3이 무엇을 참조하는지) :

변경 사항을 조정하는 방법이 명확하지 않은 경우 다음이 발생합니다.

1. HEAD 포인터는 동일하게 유지됩니다.

2. MERGE_HEAD 참조는 다른 분기 헤드를 가리 키도록 설정되어 있습니다.

3. 깔끔하게 병합 된 경로는 인덱스 파일과 작업 트리에서 모두 업데이트됩니다.

4. ...

따라서 : git reset --hard작업 트리에서 숨김 변경 사항을 제거하거나 git reset색인을 정리하고 작업 트리의 충돌을 남겨두고 수동으로 병합하려는 경우 사용하십시오.

에서 남자 자식 은닉 ( 옵션, 팝 ) 당신은 추가로 읽을 수 있습니다 :

상태를 적용하면 충돌로 실패 할 수 있습니다. 이 경우 숨김 목록에서 제거되지 않습니다. 수동으로 충돌을 해결하고 git stash drop을 수동으로 호출하십시오.

---

나는 나에게 비슷한 일이 일어났다. 파일을 아직 준비하고 싶지 않아서 파일을 추가 git add한 다음 수행했습니다 git reset. 이것은 기본적으로 내 변경 사항을 추가 한 다음 단계를 취소했지만 병합되지 않은 경로를 지우 었습니다.

---

나처럼 일반적으로 원하는 것이 작업 디렉토리의 내용을 숨김 파일의 내용으로 덮어 쓰는데 여전히 충돌이 발생 git checkout --theirs -- .하면 루트에서 사용하여 충돌을 해결하는 것이 좋습니다 .

After that, you can git reset to bring all the changes from the index to the working directory, since apparently in case of conflict the changes to non-conflicted files stay in the index.

You may also want to run git stash drop [<stash name>] afterwards, to get rid of the stash, because git stash pop doesn't delete it in case of conflicts.

---

Note that Git 2.5 (Q2 2015) a future Git might try to make that scenario impossible.

See commit ed178ef by Jeff King (peff), 22 Apr 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit 05c3967, 19 May 2015)}

Note: This has been reverted. See below.

stash: require a clean index to apply/pop

Problem

If you have staged contents in your index and run "stash apply/pop", we may hit a conflict and put new entries into the index.
Recovering to your original state is difficult at that point, because tools like "git reset --keep" will blow away anything staged.

In other words:

"git stash pop/apply" forgot to make sure that not just the working tree is clean but also the index is clean.
The latter is important as a stash application can conflict and the index will be used for conflict resolution.

Solution

We can make this safer by refusing to apply when there are staged changes.

That means if there were merges before because of applying a stash on modified files (added but not committed), now they would not be any merges because the stash apply/pop would stop immediately with:

Cannot apply stash: Your index contains uncommitted changes.

Forcing you to commit the changes means that, in case of merges, you can easily restore the initial state( before git stash apply/pop) with a git reset --hard.

---

See commit 1937610 (15 Jun 2015), and commit ed178ef (22 Apr 2015) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit bfb539b, 24 Jun 2015)}

That commit was an attempt to improve the safety of applying a stash, because the application process may create conflicted index entries, after which it is hard to restore the original index state.

Unfortunately, this hurts some common workflows around "git stash -k", like:

git add -p       ;# (1) stage set of proposed changes
git stash -k     ;# (2) get rid of everything else
make test        ;# (3) make sure proposal is reasonable
git stash apply  ;# (4) restore original working tree

If you "git commit" between steps (3) and (4), then this just works. However, if these steps are part of a pre-commit hook, you don't have that opportunity (you have to restore the original state regardless of whether the tests passed or failed).

참고URL : https://stackoverflow.com/questions/2840816/git-stash-blunder-git-stash-pop-and-ended-up-with-merge-conflicts