지난 글에 작성한 대로, 이번 글에서는 개발 과정에서 지켜야 할 절차들을 수립하는 작업을 할 것이다. 개발자가 나를 포함해 단 두 명 뿐이라서 커밋이 복잡하게 꼬인다던가 하는 일은 아마 발생하지 않을 것 같지만, 그래도 만일의 사태를 방지하고 헷갈리는 일이 없도록 꼭 지켜야 할 절차를 세워 보고자 한다.
고려할 점
- 앞서 말했듯이, 너무 복잡해서는 안된다.
- 작업을 시작할 때 branch를 새로 파고, 작업을 끝낼 때 branch를 merge 후 삭제한다. 즉 작업의 단위를 branch로 하고 작업을 하는 동안 한 branch가 다른 branch의 영향을 받지 않도록 한다.
- main branch는 항상 잘 작동하는 상태로 남겨 둔다. 즉, stable해야 한다.
생각한 절차
일단 개발자가 둘이고, 만드는 프로젝트가 버전이 확실하게 구분되어 배포되지 않고 가장 최신 버전만 사용하는 웹 프로젝트이기 때문에 굳이 많은 branch가 필요하지는 않을 것 같다는 생각이 들었다. 이전 글에서 issue들을 관리할 때 정한 대로 각 기능, 즉 새 issue를 처리할 때마다 해당 기능의 이름을 이용하여 branch를 새로 파고 작업이 완료되면 Pull Request를 올려 review 후 approve를 받아서 main branch에 merge하면 충분할 것 같다. 순서를 정해서 좀 더 자세하게 쓰면 다음과 같다.
-
새로운 기능을 구현해야 하는 경우, 먼저 그에 대한 issue를 미리 작성해 놓은 template을 이용하여 만든다. issue 안에는 issue에 대한 설명과 checkbox로 표현되는 subtask를 써 놓는다.
-
누가 issue를 처리할 지 assign을 완료한다. 이 때, issue를 해결할 개발자는 새로운 branch를 (개발자 이름)/(issue 번호)-(issue 제목) 이름으로 main에서 checkout한다.
-
코드 작성이 완료되면 Pull Request를 올린다. 이 때, Pull Request가 close되면 해당 issue 역시 close될 수 있도록 내용에는 resolved #(issue 번호)를 넣는다. 굳이 모든 코드를 작성한 상태가 아니어도 일단 Pull Request를 열어 놓고 Review Requested에 해당 PR을 올려서 review를 부탁해도 된다. 물론 이 경우 기능 완성이 되지 않은 상태이므로 approve해서는 안된다.
-
Review가 끝나서 Review Done에 위치된 Pull Request는 main branch에 merge한다. 자동으로 해당 issue와 PR은 Done으로 이동하게 된다.
Pull Request를 코드를 다 쓴 이후에 올리도록 할 까 생각했었는데 중간에 궁금한 점이 충분히 생길 수 있으므로 굳이 그럴 필요는 없다고 생각했다.
생각해 보니 Pull Request를 통해 Merge한 코드가 작동하지 않는 경우의 수도 고려해 주어야 한다. main은 항상 stable한 상태여야 하므로, main에 적용하기 전 merge 후의 버그를 수정하는 용도로 release branch를 하나 두어서 merge 이후의 오류를 수정하는 데 활용하는 것이 좋을 것 같다.
다음 목표
이전 글과 이번 글에서 협업을 어떻게 하면 효과적으로 꼬이는 일 없이 할 수 있을지에 대한 방법을 생각해 보았다. 이제 실제 서비스를 어떻게 만들까에 대해 생각해 보아야 한다. 아직 페이지 디자인이 제대로 나오지 않아서 Frontend 쪽을 건드리기엔 이른 것 같아, 다음 글에서는 Backend API를 어떻게 구성할지에 대해 생각해 보려고 한다. 전에 Django로 백엔드를 구성했을 때는 Django Template을 사용해서 Frontend와의 연결을 깊게 생각하지 않았는데 이번에는 별도의 Framework를 사용할 것이기 때문에 REST API를 적용해야 한다. 처음이라 고려해야 할 부분이 많을 것 같다..
