[해커톤] 프로젝트 회고(2)

프로젝트를 진행하면서 발생한 문제점

프로젝트를 진행하면서 Git 관련해서 크게 2가지 문제점이 발생했다.

1. Branch
   1. Fast-Forward
   2. Feature
2. Pull Reqeust
   1. Issue
   2. Code Review & Commit

1. 브랜치 이슈

이전 회고에서 발생했던 이슈를 통해 git-flow 방식으로 협업을 진행했다.
하지만 feature 브랜치 없이 develop 에서만 진행하다보니 Fast-Forward 와 관련된 이슈가 발생했다.

1-1. Fast-Forward

현재 개발이 진행되고 있는 develop 브랜치가 있다.
최신 상태의 브랜치에서 A작업자와 B작업자가 개발을 진행한다고 가정해보자.

A-Commit -> B-Commit -> B-Push

위와 같은 순서로 작업이 진행되면 A작업자는 최신상태가 아니기 때문에 merge를 한 뒤에 push를 해야한다.

즉, B-Commit은 A-Commit에 Fast-Forward한 상태이다.

이 상황을 해결하기 위해 Commit을 지워보기도 하고, Checkout을 통해 시간 여행도 해보는 등 다양한 방법으로 접근해보았지만, Git에 대한 지식이 부족하여 쉽게 해결하지 못했다.
결국 다시 Clone하여 충돌이 일어난 시점까지 Commit을 지우고, 프로젝트를 다시 최신화 했다.
팀장으로써 제대로 해결하지 못한게 많이 부끄럽기도 했고, 팀원들에게 미안한 마음이 들었다.
앞으로는 이런 일이 생기지 않도록 여러 방안을 고민하면서 아래 내용들을 추진하게 되었다.

1-2. Feature

사실 git-flow 방식을 도입하면서 굳이 Feature 브랜치가 필요할까라는 생각이 들었다.
하지만 위와 같이 Fast-Forward 이슈가 발생하다 보니 필요성을 느껴 바로 도입을 했다.
Feature 브랜치를 통해 현재 누가 어느 작업을 하는지 한 번에 파악이 가능했다.

기존 방식
develop -> 개발 -> commit -> push -> fetch -> pull -> 개발

변경된 방식
develop ~> feature/domain 분기 -> 개발 -> commit -> push -> Pull Request

이전에 비해 더 복잡해진면이 있지만, 하나의 목표를 정하고 브랜치를 분기하다 보니 기존 방식보다 능률이 더 올라갔다.

2. Pull Request 이슈

Feature 브랜치를 도입하면서 작은 단위로 개발이 되니 프로젝트 개발이 빠르게 진행되었다.
하지만 Pull Request가 올라올 때, 정확히 어떤 작업을 했는지 팀원마다 커밋 메세지 컨벤션도 다르고, 무엇을 위해 해당 브랜치로 작업을 했는지가 불분명했다.

2-1. Issue

Github Issue는 Bug를 잡을 때만 사용하기 위해 평소에는 사용하지 않고 있었는데, 다른 팀원과 알고리즘 코드리뷰를 하던 중 Issue를 통해 작업을 관리할 수 있다는 사실을 알게 되었다.
우리 팀에도 도입하면 좋을 것 같아 Issue를 생성해서 어떤 작업을 할지, 정확히 어느 기능을 구현할 예정인지 작성했다.
Feature 브랜치 만으로는 부족했던 정보가 Issue에 모여있으니 더욱 쉽게 파악할 수 있었다.

2-2. Code Review & Commit

본인이 작성한 이슈를 토대로 개발이 완료되면 Pull Reqeust를 올리게 된다.
이 과정에서 코드 리뷰를 진행하게 되는데 위에서 언급했듯이 팀원마다 Commit Message를 올리는 방식이 다르다.
때문에 Commit Message Convention을 정해서 PR을 올리도록 정했다.
우리 팀의 규칙은 아래와 같다.

[TYPE] #ISSUENUM - MESSAGE

자세한 내용은 블로그참고

확실히 Commit Message Convention을 정한 뒤로 개발 단위가 확실하게 나뉘어져 코드 리뷰가 많이 편해졌다.

정리

1. Fast-Forward 이슈 발생
2. Feature 브랜치 도입
3. Pull Request 과정에서 Issue 도입
4. Code Review를 통해 Commit Message Convention 도입

위 과정을 겪으면서 아직 Git에 대한 이해도가 많이 부족하다는 것을 느꼈다.
하지만 다양한 방법으로 문제를 해결하다보니 어느 상황에서 충돌이 일어나는지, 이런 상황에서는 어떻게 해결을 해야하는지 감을 잡을 수 있었다.