Github
이번 프로젝트를 Github로 버전관리를 하면서 했던 고민과 변화
Issue
- 초기에 우리 레포지토리도 나름 구색을 갖추기 위해, 이슈도 만들고, Project도 만들고, issue template도 만들었다. 말그대로 구색만 갖췄지 지금보다는 제대로 활용하지 못했다. 커밋의 경우는 초기에 Commit Message Convention만을 지키며 커밋했던 것같다. 하지만 프로젝트를 진행하면서 반복적으로 발생하는 문제가 있었는데 코드를 작성할 때 작업의 단위를 세세하게 정리해놓지 않으면 방향성을 읽고 이전에 고민해서 결론을 지었던 내용에 대해 다시 고민하는 일이 자주 발생했다.
- 이에 기능단위로 해당 기능을 구현하기 위해 세부사항들을 체크박스 형식으로 만들어서 적용시켜 보았다.
확실히 예전보다 돌아가는 일이 적고, 세부사항들을 나열할 때 여러가지 상황을 고려하고 더 생각해볼 수 있는 시간이 되었기 때문에 더 정확성있게 코드를 작성할 수 있었다.
시간적으로나, 기능적으로나 봤을 때 세부사항을 나열해서 document 를 작성하는 일은 반드시 필요한 일이라고 생각했다. 예전에 우아한 테크코스의 프리코스를 참여하면서 매주 미션을 진행할 때 시니어분이 항상 document에 기능을 정리하는 것을 강조했는데 그 때는 어렴풋이 와닿던 내용들이 퍼즐조각 맞춰지듯이 시니어분의 뜻을 이해할 수 있었고 프리코스의 기억을 떠올리며 최대한 세부적으로 작성했고 이를 깃허브 이슈로 만들었다.
Commit 단위
- 프로젝트 초기의 나는 대부분의 사람들이 프로젝트를 진행하기전에 깃허브 레포지토리를 열고 레포지토리에 각자 방식에 맞는 Convention을 적용시킬 것이라는 사실은 이리듣고 저리들어 알고 있었다 그렇기 때문에 당시 깃허브 활용에 대해 잘 몰랐던 나는 이전 프로젝트 때 다른 팀원이 알려줬던 깃허브 사용방식이나 컨벤션들을 다시 상기하며 이 프로젝트에도 적용시키기 위해 열심히 구글링했다 .찾아보니 커밋을 위해 여러 개발자들이 지키고자 하는 규칙들이 있었다. Commit Message Convention 을 따르고 , Commit 단위는 작을수록 좋다 등의 규칙을 알 수 있었다.
사실 예전에도 말로 몇번 들었던 적이 있었지만 다시 공부하고 다시 찾아봐도 잘 와닿지 않았던 부분이라, 당시 대수롭지 않게 생각했던 것 같다.. 이렇게 중요한 것일줄도 모르고 .. 반성해 ...
나름대로 이에 대해 공부하기 위해 구글링을 하면서 현업 프로젝트 버전관리 예시와 다른 개발자 분들이 했던 개인프로젝트의 예시를 위주로 살펴보았던 것같다. 그렇게 공부하고 고민하면서 문득 든 생각이 있었는데, 커밋의 단위도 어쩌면 시니어분이 알려주셨던 기능에 대해 document 작성하는 일과 관련해서 세세하고 꼼꼼하게 작성을 하라는 말을 토대로 이 세부사항 체크박스 커밋의 단위가 되면 어떨까라고 생각했다. 이후 프로젝트에 체크박스 단위로 이전보다 작은 커밋을 진행했고 이 계기로 이전보다 한 발자국 더 나아갈 수 있었다고 생각한다.
PR 단위
다른 부분과 마찬가지로 PR 단위로 잘 와닿지 않았다 ㄷㄷ
이부분은 커밋의 작은 단위을 필요성을 생각하면서 이슈도 더 작은단위로 만들고, PR도 지금보다 더 작은 단위로 만들면 어떨까라는 생각을 했다. 역시나 열심히 구글링을 하면서 프로젝트들을 찾아보던 와중 헤이딜러의 현업 프로젝트 버전관리 방식을 다룬 글을 보며 버전관리에 대해 더 배울 수 있었다. 헤이딜러 소속 모 개발자님 해당 글을 공유해주셔서 감사합니다.
헤이딜러의 프로젝트에서는 메인이슈 아래에 서브이슈를 만들어 이슈를 관리하고 있다는 것을 알게 되었다. 즉 이슈를 좀 더 작은단위로 관리했다. 헤이딜러에서는 메인이슈를 Jira를 사용하여 관리하고 깃허브에 서브이슈 만들어 Jira와 연동하여 History 내역을 추적할 수 있게 사용하고 있었다.
이를 참고하여 우리 프로젝트에서도 엄청 길게 나열되어있던 이슈를 메인이슈 아래에 여러가지 서브이슈를 두는 구조로 변경하였다. 이슈를 보기에도 깔끔해 보였고 한눈에 알아보기도 편했다. 또한 서브이슈로 변경한 뒤에 서브이슈 단위로 PR을 진행하니 Commit 내역도 훨씬 눈에 잘들어왔다.
PR Convention
프로젝트 초기에는 PR Convention 이 존재하지 않았다.
PR Convention 이라는 것을 설정하고 보통 프로젝트를 진행한다는 사실을 검색을 통해 알 수 있었지만 역시나 잘 와닿지가 않았다.
실제로 Convention 없이 진행하다가 위의 과정들을 통해 알게된 사실과 고민끝에 우리 프로젝트에도 다음과 같은 PR Convention을 정해서 적용하게 되었다.
#메인이슈넘버[제목]/#서브이슈넘버[제목]
이를 통해 어떤 기능이 어떤과정을 거쳐서 구현되었고, 변경되었는지 파악하기 수월했고 우리만의 구조를 갖출 수 있게 되었다.
남은 고민
- Refactoring 이나 다른 기능 구현시 자연스레 변경되는 코드의 경우 커밋을 어떻게 가져가야할지 고민이 된다.
- 커밋은 커밋메시지에 포함되는 내용들로만 단위를 가져가고 싶은데, 어쩔수 없이 함께 변경되는 코드같은 경우는 커밋이 애매하다는 생각이 든다.
- 또한 기능 구현이나, 기능의 요구사항 변경으로 인한 코드의 변경이 있을 때는 어떤식으로 이슈를 만들어야할지 고민이 된다.
- 현재는 해당 기능을 구현하기 위해 정의한 메인이슈 내용에 변경관련해서 날린 PR을 날린다. (따로 서브이슈로 생성하진 않는다.) 예를 들면 #메인이슈넘버[제목]/[제목] 이런식으로.
- 이후에 시간순으로 해당 PR을 태그 + 부연설명으로 히스토리를 관리하고 있는데 더 고민해봐야할 것 같다.