git. merge strategy

회사에서 merge 전략을 구분지어서 사용하고 있어서 관련 정책을 조사해보았다.

- 개발 브랜치로 sync할때는 merge commit 권장 

- 실제 운영으로 배포할때는 squash strategy 권장 

 

 

1. create a merge commit 

 

- 가장 심플하게, 커밋 내역과 함께 merge commit이 생성

 

2. squash and merge

 

- merge할 브랜치의 commit을 전부 하나의 commit으로 합친 후 타겟 브랜치에 병합

- 장점은 merge commit이 남아서 merge된 브랜치가 있었다는 것을 히스토리에서 알아볼 수 있음 

- 단점은 merge된 브랜치의 변경 내역이 하나의 commit으로만 남기 때문에 어떠한 과정으로 변경되었는지에 대한 정보를 알 수 없음

 

 

3. rebase and merge 

 

- 브랜치가 타겟 브랜치에서 변경된 것처럼 브랜치 히스토리의 베이스를 변경해 merge
- 장점은 commit 히스토리를 단순하게 만들어서, 하나의 브랜치에서 작업한 것처럼 보여짐 

- 단점은 merge commit이 남지 않기 때문에 병합시킨 브랜치가 언제 병합되었는지의 시점을 알 수 없다는 점

 

 

 

그렇다면 다시 돌아가서, 내가 생각한, 이런 정책을 쓰도록 권장한 이유는 다음과 같다. 

- 배포할때 squash 전략을 권장하는 이유는 모든 변경사항이 하나로 합쳐지기 때문에 rollback이 비교적 쉬운 장점이 있는것 같음 

- 개발 내용을 sync할때는 변경 히스토리들을 모두 다 가져오면 좋기 때문에 merge commit을 권장하는 것 같음

 

 

 

참고 블로그 

- 각 전략별 실제 사용 예시 > https://nuritech.tistory.com/33

- 장점/단점 설명한 글 > https://velog.io/@yujuck/Git-Merge-%EC%A0%84%EB%9E%B5

- git rebase vs merge vs squash 그림과 함께 > https://dev.to/devsatasurion/git-rebase-vs-merge-vs-squash-how-to-choose-the-right-one-3a33

- 다른 회사에서 사용하는 전략 예시(라고한다)  > https://meetup.nhncloud.com/posts/122

 

----

> develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지 후에 feature 브렌치를 삭제해버리는 점을 떠올려 보면, feature 브렌치의 커밋 히스토리를 모두 develop 브렌치에 직접 연관 지어 남길 필요가 없습니다.

> master - develop 브렌치간 머지 : Rebase and Merge가 유용합니다. develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문입니다.

> hotfix - develop, hotfix - master 브렌치간 머지 : Merge 또는 Squash and Merge 모두 유용합니다. 때에 따라 골라 사용하면 좋을 것 같습니다. hotfix 브렌치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용하면 됩니다.

----

 

 

이외에도 전략은 아니지만, 좀더 이해하고자 한다면 octopus , fast forward, 3-way merge 을 찾아보면 좋을것 같다.