Git merge --squash의 필요성을 느끼게 되었다.
일단 결론부터.
앞으로는 어지간한 merge에는 merge --squash를 사용할 것 같다. 깔끔한 라인을 위한 노력이라고 할까.
git merge --squash {branch name}Git에서 --squash 옵션을 사용하여 머지하게 되면 지금까지의 작업 내역을 하나의 커밋으로 만들어서 머지가 가능해진다.
- master에서 일단 작업용 feature 브랜치를 만들고
- feature에서 로컬용을 하나 만들고 이것저것 신나게 커밋하면서 작업하고 일정 작업이 정리되면 feature에 merge —squash
- release-dev에 feature를 머지 & push
- 개발 전달을 위해 release에 feature를 머지 & push
- 오픈까지 작업이 일단락되면 release를 master에 머지
실질적으로는 2번 과정은 필요가 없다면 없는 작업이다. 그냥 feature에서 모든 작업과 커밋을 진행하면 되니까. 그저 깃을 사용하는 데 있어 좀 더 다양한 사용방법을 익히고 좀 더 잘 다루기 위한 방법이라 생각되기에 앞으로는 이러한 방식으로 작업을 해볼 예정이다.
git merge —squash까지 도달하게 된 배경
최근에 참가 중인 프로젝트들은 이제 거의가 Git을 사용하고 있다. 레거시 프로젝트나 폐쇄망 프로젝트의 경우 아직도 svn을 사용하는 곳들이 있긴 하지만. 약간 불편함이 없진 않지만 svn이 나쁘다는 것이 아니라 이제는 Git도 잘 써야 한다는 것이니까.
더구나 이번에 참가 중인 프로젝트는 마크업을 혼자 하고 있다 보니 소스 관리도 내 맘대로라 할 수 있다. 전임자가 정해둔 프로세스는 지키지만 소스 관리는 전적으로 혼자 하니 그동안 약간 게을리했던 Git을 좀 더 많이 자주 틀리며 사용하고 있다.
대부분의 프로젝트들이 그렇지만 현재 프로젝트의 merge 프로세스는 다음과 같다. 작업 시작 시 master에서 feature
브랜치를 생성해서 프로젝트를 진행하고 작업이 일단락되면 release-dev를 통해 내부 검수를 진행하고 개발에 넘겨도 좋을 때 feature를 release에 merge 시키고 오픈까지 모든 작업이 마무리되면 release를 master에 merge 시키는 과정을 거친다. 일부에서는 develop 브런치도 두고 hotfix도 두는 것 같지만, 현재 규모에서 그것도 작업자가 혼자인데 너무 많은 관리 포인트가 생기는 것을 피할 필요가 있었다.
이건 정말 귀여운 수준의 예인데.. 줄기가 몇 가닥씩 생기면 정말 어지럽다. 특히 오픈 일정은 다르지만 동시에 진행되는 작업의 경우 더 복잡해지기도 한다. 이렇다 보니 이 줄기를 좀 더 잘, 깔끔하게 정리할 수 있는 방법은 무엇일까를 고민하게 되었다. 커밋은 작업 이력이기 때문에 중간중간 계속 커밋해 두는 게 좋다는 게 개인적인 생각이다 보니 시도 때도 없이 커밋을 하곤 한다. 그리고 로컬에 대한 불신(?)으로 커밋을 계속 날리고 있었는데..
여러 프로그램을 사용하면서 편한 게 없을까 건드려 보고 있는데 Fork를 사용해 보면서 깜짝 놀랐다.(프로그램마다 각각의 기준이 있고 표현 방식이 다르다고는 하지만..) 이건 누가 봐도 심하다고 생각될 것 같은 현상. VSCODE에서 볼 때와 다르게 너무나 많은 줄기를 보면서 진짜 깜짝 놀랐다. 너무 많은 커밋과 merge가 불러오는 참상을 볼 수 있었다. 이렇게 하지 않아도 가능한 것을 아무 생각 없이 일을 하면 어떤 결과가 나오는지 느낄 수 있었다.(이제는 이러지 말아야지..)
슬슬 인수인계받은 소스들과 업무가 손에 익기 시작하면서 소스관리에 대한 생각이 들며 체계적으로 정리를 하고 싶다는 생각이 들었다. 그래서 찾아보다 얻게 된 결론이 merge --squash였다.
일단 방향은 잡았으니 작업을 해보고 변화가 필요하다 싶으면 다시 정리해 봐야 할 것 같다. 분명히 필요 없다면 필요 없는 과정인데.. 자기만족을 위한 고행??