Feature 브랜치 이슈는 어떻게 관리해야 할까?
프로젝트 관리 시스템을 운영한다면 마일스톤은 기본으로 사용하게 됩니다. 이 마일스톤에는 여러 이슈를 추가하고요. 편의상 마일스톤 이름에는 앞으로 릴리스할 버전을 넣습니다. 그렇게 하면 개발자가 쉽게 구별할 수 있으니까요. 다만 개발 단계에 따라 세분화해 마일스톤을 구분하지는 않습니다. 즉 1.0.0.Alpha, 1.0.0.Beta 이렇게 마일스톤을 사용하지 않고 1.0.0 – Alpha를 사용하다 1.0.0 – Beta로 이름을 바꿉니다. 개발을 마치면 1.0.0으로 바꾸고 닫습니다. 이렇게 하면 1.0.0에서 그동안 진행한 내용을 모두 볼 수 있습니다. 물론 환경에 따라서는 개발 단계별로 마일스톤을 운영해야 할 수도 있습니다만 제 경우는 그렇게 세분화할 필요를 아직 못 느낍니다. 그렇게 하면 오히려 더 번거로운 상황이 될 수 있기 때문입니다.
마일스톤에 대한 얘기를 잠시 했는데 마일스톤 대부분은 버전에 따라 운영하므로 별 문제가 없습니다. 해당 버전 개발을 마치면 마일스톤 역시 마치고, 그 마일스톤에는 해당 버전에 대한 내용이 모두 있으므로 찾아 보기도 간단합니다. 하지만 기능 개발을 따로 하려고 만드는 feature 브랜치는 좀 생각해 봐야 합니다.
먼저 브랜치 정책에서 설명한 그림을 다시 보는 게 좋겠습니다.
feature 브랜치는 특정 버전에 속하지 않으며 마치는 시점에 따라 병합할 대상 버전이 달라질 수 있습니다. 그러므로 feature 브랜치를 만들면 마일스톤 역시 따로 만드는 게 좋습니다. 그런데 마일스톤을 따로 만들면 개발을 마친 후 병합할 시점에 이 이슈를 어떻게 할지가 문제입니다. feature 마일스톤의 이슈를 모두 병합할 버전의 마일스톤으로 옮겨야 할까요? 릴리스 버전 기준으로 관리하므로 일견 괜찮아 보입니다. 하지만 무엇보다 이슈를 일일이 옮겨야 하는 게 불편합니다. 또한 저장소에 남아 있는 feature 브랜치와 대응해 마일스톤을 찾아 볼 수 있으면 더 좋을 겁니다. 물론 이 feature를 어느 마일스톤에 반영했는지도 찾을 수 있어야겠죠.
이런 요구 사항에 맞춰 생각해 보니 결론은 ‘feature 브랜치 병합 이슈를 만들자‘입니다. 일반적으로 저장소에서 브랜치 사이에 병합할 때는 마일스톤에 이슈를 만들지 않습니다. 브랜치 정책에 따라 병합할 것을 약속하기 때문에 일일이 이슈를 만든다면 번거롭기만 합니다. 하지만 feature 브랜치는 일반적인 브랜치와 성격이 조금 다릅니다. Develp, Hotfix 브랜치 등은 그 자체로 완전한 릴리스를 만들므로 브랜치에서 작업을 마칠 때 마일스톤 역시 마치면 되지만 feature 브랜치는 그 브랜치 자체만 끝났을 뿐 릴리스까지는 아직 멀었습니다. 그러므로 병합할 때 병합 대상 마일스톤에 이슈를 만들어 어떤 feature 브랜치를 병합하는지 기록한다면 마일스톤에서도 관련 내용을 좀 더 쉽게 추적할 수 있습니다.
