211015(금) - 1.0.0 release 및 앞으로의 Git 전략

목차

• 1.0.0 release 및 앞으로의 Git 전략

1.0.0 release 및 앞으로의 Git 전략

최종 데모를 앞두고 정식 버전을 release 하면서, 앞으로의 Git 전략을 같이 이야기했다. 이전에는 데모를 앞두고 한 번만 main 브랜치에 작업을 반영했지만, 이제는 이러한 방식을 수정하기로 했다. 앞으로의 데모가 한 번 남았을 뿐만 아니라, 이전의 방식을 사용하면 기능 상의 버그나 수정 사항이 최신 코드에 반영되지 않기 때문이다.

main 브랜치를 업데이트하는 방식을 먼저 이야기했다. 매번 main 브랜치에 최신 코드를 유지하기 위해 main 브랜치에서 새로운 브랜치를 생성해서 하는 방식은 기존에 develop 브랜치와 main 브랜치를 사용하는 방식과 크게 다르기도 하고, 팀원에 의해서 코드가 바로 달라질 수 있다는 위험성이 있다고 생각해서, 기존의 develop 브랜치와 main 브랜치 전략을 유지하기로 했다. 다음으로, 기존의 방식을 유지한다면 main 브랜치에 merge 하는 시점과 방식은 어떻게 할 것인지에 대해서 논의했다. 개인적인 생각으로는 코드에 변경이 있는 경우 그날 그날 변경 사항들을 취합해서 main을 업데이트하면 되지 않을까 생각했는데, 따로 시간을 조정해야 하는 불편함이 있어서 전체 회의가 잡혀있는 월 수 금에 변경 사항이 있을 경우, main 브랜치 업데이트를 함께 진행하기로 했다.

시멘틱 버저닝은 사실 잘 지켜지고 있지 않은 부분이었다. 하지만, 정식 배포가 이루어졌기 때문에 조금 늦었지만 제대로 진행해 보기로 했다. 그 방식으로 major, minor, patch 각 부분의 규칙을 정했는데, major는 대대적인 수정이 있는 경우, 예를 들어 전체적인 디자인 변경이나 개편이 있는 경우, minor는 기능의 추가 또는 삭제가 있는 경우 숫자가 올라간다. 마지막으로 patch는 버그를 수정하는 경우 변경하기로 했다. 전체적인 틀은 이렇게 잡고 개인적으로 궁금했던 부분은 이 숫자가 변경되는 기준을 유저의 입장으로 할 것인지였다. 예를 들어, 애플리케이션의 성능 개선이 있는 경우, 사용자(유저)는 느끼지 못할 수도 있다. 이런 상황에서 patch 부분 숫자를 올릴지 같이 이야기를 했는데, 유저에게 유의미한 업데이트가 아닐 수 있으나, 또다른 사용자인 우리 팀의 개발자들에게는 기록 그 자체로 의미가 있을 수 있기 때문에 patch 숫자를 증가시키기로 했다.