티스토리 뷰

반응형

git merge 시 diff가 없게끔만 설정해주면된다. 2021년 11월 15일에 적용된 기본 MERGE 전략인 ORT 전략을 기준으로 말씀드립니다. 이전에는 RECURSIVE 전략이었슴.

(이 글은 동료와 대화중에 캐치하여 작성하게 됨 나는 변경사항이 같아도 다른 커밋이면 컨플릭트 난다고 알고 있었음. 추가 글에서는 RECURSIVE 전략이 진짜로 컨플릭트 나는지 확인해보겠음)

단일 커밋에 대한 머지

feature/a 브랜치와 feature/b 브랜치 가 동일한 변경점을 가질 경우 conflict 없이 merge할 수 있다. 
즉 COMMMIT A와 COMMIT B가 동일한 변경일 경우 충돌없이 merge가능.

여기서 더 나아가, 여러 줄에 대해 수정해보자, FEATURE/A에 대해, REBASE 하지 않아도 동일한 변경점을 가진다면 충분히 MERGE할 수 있다.

일반적으로 단일 커밋에 대해서 변경점을 수정하는 것 보다 커밋 series에 대해서 일부 변경점을 수정하고 싶어할 것이다.

여러 커밋에서 일부 커밋 변경 사항 을 동일하게 한 후 MERGE

FEATURE/A 와 FEATURE/B는 현재 똑같다. 여기서 FEATURE/A 와 FEATURE/B를 각각 커밋 할 것인데 변경사항은 다음과 같다.

FEATURE/A

FEATURE/B

나는 FEATURE/A와 FEATURE/B에 대해 blahblah 동일한 변경점을 기입했고, FEATURE/A는 한번더 가서 mlmlmlml을 입력하였다.
MERGE한 경우에 대해 다음을 결과를 기대한다.

"""
blah blah
mlmlmlmlml
"""

하지만, 여기서 머지 하면 어떻게 될까? CONFLICT가 난다.

 

CHERRY PICK은? 정상적으로 CHERRY PICK 이 된다. 왜? "blah blah" 까진 같으니까. "mlmlmlmlml" 만 다르다. 그래서 "mlmlmlmlml"만 더하게 된다. 

그럼 다음 결과가 나온다.
""""
blah blah
mlmlmlmlml
"""

그 후 MERGE 하게 되면 CONFLICT 없이 잘 된다. 왜? DIFF 알고리즘이 다른 점을 찾지 못한 것이다.

 

결론

MERGE시 GIT DIFF에 따라 동작하게된다. CHERRY PICK은 변경점에 대해 가져오므로 충돌 우려가 적다. merge는 "blah blah"가 겹치고 mlmlml만 다르지만 왜 충돌이 나게 되었을까? 3-way merge 전략 때문이다. 베이스 기준으로(blah blah, mlmlml이 적혀져 있기 전 부모 브랜치!) 대해서 diff 알고리즘이 FEATURE/A, FEATURE/B에 대해 하위 에 "두 라인(blah blah)" 또는 "4 라인(blah blah + mlmlmlml)" 에 대해 변경사항이 다르다고 판단했기 때문이다.

diff 알고리즘에 대해 좀더 좋은 컨텐츠는 다음을 참고 부탁드립니다.

diff3 알고리즘+논문이 담긴글 블로그 https://blog.npcode.com/2012/09/29/3-way-merge-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98%EC%97%90-%EB%8C%80%ED%95%B4/]

diff3 알고리즘 그림 + 글 블로그 https://wonyong-jang.github.io/git/2021/02/05/Github-Merge.html

반응형