반응형

 

 

 

프로젝트 처음으로 해보면서 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 내역이 붙는다.

Squash Merge 후 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