프로젝트 처음으로 해보면서 Github의 다양한 기능을 공부하게 된 것 같다..
깃허브로 협업을 하다보면 Pull Request에서 머지 전략을 선택할 수 있도록 되있는 것을 볼 수 있다.
깃허브에서 pull request를 merge 할 때 총 3가지의 방법중 선택할 수 있다.
머지 전략은 각 브랜치 전략에 맞춰서 사용하면 된다.
Merge Commit
흔히 잘 알고있는 merge 전략이다.
기존 브랜치의 모든 commit을 그대로 붙이고 merge commit 까지 남기는 방식이다.
A 브랜치에서 B 브랜치로 PR을 해서 Merge Commit 전략으로 Merge 한다고 생각해보자.
그러면 아래와 같이 commit이 남을 것이다.
A branch : commit1 -> commit2 -> commit3
B branch : commit1 -> commit2 -> commit3 -> Merge pull request #번호 ~~
이런 식으로 merge된 B브랜치에 A브랜치의 commit 내역 + merge 됐다는 commit 까지 같이 남는다.
Squash and Merge
이건 commit을 모두 하나로 뭉쳐서 commit 1개만 남기는 전략이다.
예를 들어 A 브랜치에서 B 브랜치로 올린 PR을 'Squash and Merge' 전략으로 merge 한다고 하면 아래와 같이 남는다.
A branch : commit1 -> commit2 -> commit3
B branch : commit
A 브랜치의 커밋 내용들을 모두 하나로 뭉쳐서 commit을 하나만 남기는 전략이다.
커밋의 타이틀에 원하는 커밋 내용을 쓸 수 있고 body에는 자동으로 commit 내역이 붙는다.
'Update README.md' 라는 내용의 커밋을 3개 남긴 후에 Squash Merge한 내용이다.
커밋 내용은 원하는대로 바꿔쓸 수 있다.
그리고 merge 커밋의 body에 자동으로 병합 전 커밋 내용이 나와있는 것을 볼 수 있다.
Rebase and Merge
이건 아예 rebase 하는 전략이다.
브랜치 pull 이나 push할 때 config에서 rebase를 설정하거나 옵션으로 rebase를 줄 수 있다.
Rebase and merge 전략도 그 rebase와 비슷하다.
이 전략을 이용하면 merge commit 없이 commit을 그대로 붙여놓을 수 있다.
이번에도 A 브랜치와 B 브랜치로 예시를 들어봤다.
A branch : commit1 -> commit2 -> commit3
B branch : commit1 -> commit2 -> commit3
이런식으로 A 브랜치가 B 브랜치의 부모 브랜치가 되고 merge commit이 붙지 않는 것을 볼 수 있다.
우리 팀에서는 feature 브랜치에서 dev 브랜치로 merge 할 때는 되도록이면 commit을 다 남겨놓기 위해 'Merge Commit'을 사용하기로 했고
dev에서 main 브랜치로 merge 할 때는 'Squash and Merge'를 사용하기로 했다.
어떻게 merge commit을 남길 것인지에 따라서 merge 전략을 골라서 사용하면 된다!
읽어주셔서 감사합니다. 😍
오개념에 대한 지적은 언제나 환영입니다!
'GIT' 카테고리의 다른 글
[GIT] 협업할 때 유용한 명령어 (CLI 명령어) (0) | 2022.09.05 |
---|