Conflict

Merge Conflict

• 다른 소스의 변경내용을 현재 작업중인 브랜치에 머지, 혹은 통합 시 발생

• integration은 브랜치 머지에만 발생하는것 뿐만 아니라,

• rebase, interactive Reabse, cherry-picking, pull, stash 적용시에도 가능

• 브랜치 머지는 보통 스스로 문제를 해결하고 변경사항을 통합할 수 있다.

Merge Conflict 발생

언제, 어떻게 머지 컨플릭이 발생하는지 파악

머지 컨플릭이 발생하는 방법과 시기

• 모순된 변화가 이루어지는 시기

  • 즉 시스템이 무엇이 옳은지 그른지 판단할 수 없는 상황에서 사람의 판단이 필요

  • ex: 같은 코드 라인에서 두개의 다른 브랜치에서 두 개의 커밋으로 변경된 경우, 어느 것이 더 나은지 판단해야하는 경우

  • ex: 파일이 한 브랜치에서 수정, 다른 브랜치에서 삭제된 경우

발생 여부 파악

머지 컨플릭이 발생했는지 확인하는 방법

• 깃 시스템에서 자동으로 안내

• 머지/리베이스 실패시 바로 안내

실행 취소 후 재시작 방법

머지 컨플릭을 실행 취소 후 다시 시작하는 방법

• 머지 컨플릭 이후에 작업을 계속 진행하려면 컨플릭 처리가 필요

  • 컨플릭 해결

  • 컨플릭을 일으킨 작업 중단 / 실행 취소

$ git merge --abort
$ git rebase --abort

• 실행 취소 후 재시작 방법

  • 대부분 --abort 매개변수를 사용하는 것 만큼 간단

  • 머지/리베이스가 실행 취소하고 컨플릭 발생 전으로 복귀

  • 컨플릭하는 파일을 해결하기 전부터 더이상 나아갈 수 없을때에도 이용 가능

Git에서 어떻게 보여지는지

머지 컨플릭이 어떻게 보여지는지 이해

• 문제가 발생한 부분을 <<<<<<<<<, >>>>>>>>> 로 표기

1. 첫번째 마커 뒤의 내용은 현재 작업중인 브랜치(HEAD)

2. ========= 서로 컨플릭하는 두 변경 내용을 구분

3. 다른 브랜치의 변경 내용(develop)

위 라인을 해결하는 것이 컨플릭을 해결해나가는 일

Git에서 어떻게 해결하는지

머지 컨플릭을 어떻게 해결하는

• 변경 완료시 원하는 모양으로 표시가 되도록

• 다른 사람의 작업인 경우 의사소통 필요

• 전용 도구를 사용하여 시간과 노력을 줄일 수 있음

  • Tower Application

• 복잡한 컨플릭에서 도구를 사용하면 보다 유용

• 원하는 도구는 git config 명령어를 사용하여 구성 가능

$ git config --global merge.tool p4merge
$ git config --global diff.tool p4merge

Built-in merge tool

컨플릭을 최소화 시키기

컨플릭 발생 상황을 최소화 시킬 수 있는 방법을 알아보자.

구조화된 프로젝트

• 피처의 할당 및 구현

  • 도메인 / 화면에 나누어서 분배

• 의존성의 분리와 느슨한 결합

  • 이를 나누는데 유리

  • Presentation Layer 뿐만 아니라 Data / Domain (Model, Repository, UseCase) 모두 각각 나누어서 분리 / 구분

  • 충돌의 발생을 상당부분 해소

  • 관리의 불편함이 발생 가능 (한 눈에 보기 어려움)

  • 이를 방지하기 위한 아키텍처 맵/ 서비스 맵 / 의존성 그래프 필요

브랜치 최신화

• 충돌은 브랜치가 origin의 head와 멀리 떨어질수록 커짐

• 주기적인 pull / rebase는 로컬에서의 컨플릭을 줄여주는 역할

브랜치는 작게 유지

• 충돌은 브랜치가 origin의 HEAD와 간극이 클수록 커짐

• 하나의 커밋은 작은 단위로 (충분히 그 의미를 포함할 수 있는)

• Pull Request도 마찬가지 (충분히 그 의미를 포함할 수 있는)

• 결국 Origin과 동떨어진 작업은 나중에 크게 돌아오게 된다.

무엇을 해야할지, 어떻게 해야할지 정의하고 작업 진행

• 하나의 피처 구현/완성은 그 의미를 충분히 파악하고 이것을 반영했을 때 완성

• ㄴ 아닌 경우, QA 도중의 이슈 발생 혹은 배포 이후 핫픽스의 발생 가능

Feature를 작업하는데 있어서 무엇을 해야할지(What), 어떻게 구현할지(How)를 이해하고, 이를 토대로 영향 범위를 산정하면, 부담이 덜함

잘못된 Rebase로 인한 문제 복구 (reflog)

git은 head 포인터의 모든 움직임(commit, merge, rebase, cherry-pick, reset) 등의 동작들을 모두 reflog에 기록함

git log / reflog 차이점

git log와 reflog의 차이점 이해

git log

• 현재(Head)로부터 부모 브랜치를 거슬러 흘러가며 print를 반복

git reflog

• 비공개 된 workspace 관련 작업 기록

• 조상목록을 거치지 않음

• HEAD가 과거에 가리킨 모든 커밋을 순서대로 나열

• 문서 편집기의 실행 취소 기록과 유사

• repository의 일부가 아닌 로컬 기록

• 커밋과 별도로 저장

• .git/logs/refs/heads/ 에 로그파일 존재

• 모든 브랜치의 로컬 커밋 추적

• 90일후에 정리되지만 조정 가능

  • git config gc.reflogExpire 180.days.ago (또는 never)

유실된 커밋 복구

머지 컨플릭이 발생했는지 확인하는 방법

커밋 유실 발생 시나리오

• 일부 커밋을 제거하기로 결정

• git reset으로 커밋을 제거

  • git reset --hard [hash]

• 잘못된 생각임을 깨달음

  • 유실된 커밋 확인 및 복구 (git reset 사용 ㄱㄴ)

  • git reset --hard [hash]

    • 되돌릴 커밋의 해쉬

• 패닉 💣

유실된 브랜치 복구

머지 컨플릭을 실행 취소 후 다시 시작하는 방법

• 피처 브랜치를 제거하기로 결심

• 브랜치 제거

  • git branch -D feature/login

  • git branch -vv (브랜치 전체조회)

• 잘못된 생각임을 깨달음

• 패닉 💣

브랜치 제거 복구

• git reflog로 기록 살펴보기

  • 제거된 브랜치의 마지막 커밋 해쉬값을 복사

• git branch 명령어로 해당 상태값의 브랜치 생성

  • 커밋 hash를 뒤에 넣어줌으로써 브랜치가 해당 커밋을 가지고 있는 상태로서 복구 할 수 있게됨

$ git reflog
$ git branch feature/login c7414ed
$ git brnach -vv