Git 3 - stash/reset/conflict

git stash

작업한 내용(index의 코드변경사항)을 임시저장하고 숨겨놓는다.

• exp 브런치 작업을 다 끝내지못하고 master 브런치의 작업을 하러 가야하는 상황이 발생한다.
• exp 브런치의 수정내용을 커밋하기도 애매하고, 커밋 안하면 체크아웃할 수가 없다.
• 물론 체크아웃이 가능하다. 문제는, 체크아웃하면 master 브런치의 index에 exp 브런치의 코드 수정사항이 뜬다. 곤란하다. exp 브런치의 내용이 master 브런치에 영향을 주는 것이다. 각 브런치는 병합되기 전까진 서로 독립적이여야 한다. 이 때 stash로 이 문제를 해결한다.
  
• 작업 공간과 작업 중이던 exp의 상태(정보)가 저장되었다.
  • 참고 : git버전관리(modified)를 하는 파일에 대해서만 저장한다.
• 이러고 master 브런치로 가서 status를 확인하면 index가 깨끗할 것이다.
• master의 작업을 마친 후 다시 checkout해서 exp로 왔다.
• exp stash를 복구하려면 어떤 명령어를 입력해야 할까?

git stash apply

"가장 최근 stash"를 복구한다.
자, 그렇다면 stash apply를 통해 정보를 다시 불러왔다. 그럼 해당 stash 정보는 사라질까? 삭제하기 전까진 계속 살아있다.

git stash drop

"가장 최근 stash"를 삭제한다.

git stash pop

== git stash apply; git stash drop
말 그대로이다. 가장 최근 stash를 복구하고 해당 stash를 삭제한다.

reset --hard OOO

master가 과거의 버전 OOO commit을 가르키고, 하위 버전들을 삭제한다.
하지만, git은 "웬만하면 삭제하지 않는다."
reset과 같은 중요한 작업들은 ORIG_HEAD 파일에 저장된다.

reset의 종류

• soft : repository 취소
• mixed : index + repository 취소
• hard : workingDirectory + index + repository 취소
• merge

merge & conflict

다양한 브런치들 병합을 했는데 충돌이 일어났다. 원인이 무엇일까?
서로 다른 브런치에서 같은 코드를 수정하면 Automatic merge가 실패하고 conflict가 발생한다. git은 모를 수 밖에 없다. 어떤 코드로 병합을 해야할지.
이 때, kdiff3와 같은 툴을 사용할 수 있다.

어떤 코드를 채택해서 병합할지 선택해야 한다!
base는 분기 및 작업되기 이전에 존재했던 동일했던 코드이다.
base를 채택할지, master의 변경사항을 채택할지, exp의 변경사항을 채택할지 정해야 한다.

merge 방식

• 2 way merge
  Base를 참고하지 않는다. 이게 단점이다.
  A와 D의 경우에서, 어떤 경우가 코드가 변경된 사항인지 알 수가 없게된다.
  따라서 A,C,D에서 conflict가 발생한다.
• 3 way merge
  base를 참고한다.
  2 way merge보다 훨씬 좋다. 보통 이 방법으로 merge한다.
  base라는 과거 커밋의 상황을 볾으로써, 판단 기준이 더욱 명확해진다.
  따라서 C에서만 conflict가 발생한다.