들어가기에 앞서…
이번에 회사에서 인턴을 경험하면서 사수분께 많은 것을 배우고 있습니다.
(항상 감사합니다)
그래서 숙제로 스쿼시 머지라는 것에 대해서 한번 알아보라고 하셨는데, 앗! 시마타! 분명 들은 적있는데....
예전에 간단하게 언급된 내용이었는데 머리를 치며 이번에 새벽을 새더라도 공부를 해보려고 합니다.
사전 개념
Merge란?
gitFlow 전략을 예로 설명하면develop브런치에 대해서 기능을 구현할때feature/~~라는 새로운 브랜치로 작업을 진행한 이후develop브런치에 다시 붙이는 과정을 Merge라고 한다.그리고 이러한 Merge 방식에 대해서는 3가지 종류가 있다.
1. Merge
2. Squash and Merge
3. Rebase and Merge
예시는 모두 develop에서 feature/~~ 브런치를 생성한 후 develop으로 붙이려는 상황으로 생각해주면 더 잘 이해가 되실겁니다.
Merge
간단하게 사전 개념에서의 내용 그대로 한번 읽어주시면 감사하겠습니다.
사진을 통해 보면
분류되었던 브런치에 대한 모든 commit기록들이 살아 있는 상태로 develop에 붙게 됩니다.
해당 Merge 방식의 장점으로는 다른 분기의 브런치들의 commit기록을 통해서 작업의 수정자와 작업한 모든 순간을 확인할 수 있다는 것입니다.
장점이 곧 단점으로 모든 commit기록을 확인하기 때문에 쓸데없이 오타를 지우거나 변수명을 변경하는 별거 없는 변경에 대해서도 기록이 남기에 원하는 변경사항을 찾는데 시간이 오래 걸릴 수 도 있습니다.
Squash and Merge
Squash and Merge 방식도 똑같이 feature/~~ 를 예시로 들 수 있는데 최종 머지하는 방식에서 개발자가 feature에서 작업한 모든 commit 기록들이 하나가 되어 머지가 됩니다.
Squash 방식의 장점으로는 쓸데없는 commit 기록을 보지 않고 오로지 내가 분리한 기능에 대해서 붙이는 것을 확인할 수 있기에 merge된 것에 집중할 수 있습니다.
단점은 세세한 commit 기록을 볼 수 없기에 만약 한명이 아닌 두 명 이상이 작업한 브런치인 경우 작업한 기록이나 사람을 특정할 수 없다는 단점이 있습니다.
Rebase and Merge
Rebase and Merge 방식 또 결국은 같지만 결과를 보았을 때 feature/에 대한 commit 기록에 develop 앞에 붙게 되어 모든 작업이 develop에서만 이루어진 것처럼 branch를 관리할 수 있습니다.
장점으로는 develop 브런치의 commit기록을 남김으로써 코드의 변화를 빠르게 확인할 수 있습니다.
단점으로는 하나의 브런치에 모든 commit 기록이 뭉쳐있어 찾고 싶은 commit 기록이 있는 경우 탐색에 어려움이 있습니다.
