测验：重复冲突与合并策略

merge.conflictStyle=zdiff3 가 충돌 표시에 더해 주는 칸은 무엇인가?

• 충돌을 일으킨 커밋의 작성자와 시각
• 두 브랜치의 공통 조상에 있던 내용
• 같은 파일에서 충돌하지 않은 부분의 요약
• git 이 자동으로 제안하는 해결안

rerere.enabled true 로 켠 뒤 같은 충돌이 다시 났다. git 이 하는 일은?

• 충돌을 건너뛰고 병합 커밋을 자동으로 만든다
• 이전 해결과 다르면 병합을 거절한다
• 기록해 둔 해결을 작업 트리에 적용하되 스테이징은 하지 않는다
• 기록해 둔 해결을 적용하고 자동으로 스테이징한다

rerere 기록에 대해 옳은 것은?

• .git/rr-cache 에 있어 clone 이나 push 로 공유되지 않는다
• .gitattributes 에 적혀 저장소와 함께 공유된다
• 원격에 push 할 때 함께 올라가 팀이 같은 해결을 쓴다
• 커밋 객체 안에 담겨 이력과 함께 따라간다

충돌을 잘못 해결했고 rerere 가 그것을 기억해 버렸다. 무엇을 하는가?

• rerere.enabled 를 false 로 바꾼 뒤 다시 켠다
• .git/rr-cache 전체를 지우고 병합을 처음부터 다시 한다
• git rerere forget <경로> 로 그 기록만 지운다
• git rerere gc 로 오래된 기록을 정리한다

git merge -X ours other 의 결과는?

• other 의 트리를 통째로 버리고 우리 트리를 그대로 둔다
• 충돌한 자리만 우리 것을 고르고, 충돌하지 않은 other 의 변경은 들어온다
• other 를 조상으로만 붙이고 파일은 하나도 바꾸지 않는다
• 충돌이 나면 병합을 중단하고 수동 해결을 요구한다

git merge -s ours other 를 쓰기에 맞는 상황은?

• other 의 변경 중 충돌하는 부분만 빼고 받아들이고 싶을 때
• other 를 리베이스 없이 일직선으로 합치고 싶을 때
• other 의 새 파일만 받고 기존 파일 변경은 무시하고 싶을 때
• other 를 합치지 않기로 했다는 사실을 이력에 남기고 다음부터 병합 대상에서 빼고 싶을 때