오이스터 에이블에 합류한 지 어언 한달.
현재는 bit-bucket 을 사용하여 새로 런칭하는 Hero8앱의 랜딩페이지 구현을 시작중에 있다.
처음 꾸려진 내부 dev 팀 이다 보니 기술 스택을 정하는 것 부터 git convention까지, 우리의 손으로 하나 하나 만들어 가는 중이다.
그 중에서도 개발자 협업의 중요성을 절실히 느꼈던 것이 바로 git flow.
보드에 그림을 그려가며 한 명씩 자신이 경험한 git flow 를 설명하고,
수정할 것은 수정하고 보완할 것은 보완한 결과, 현재 우리 프로젝트의 사이즈와
개발팀 상황을 고려한 최적의 convention을 함께 정립했다.
코딩은 각자 할 수 있지만, git 은 코드가 엉키거나 잘못 merge 될 경우 팀 전체가 (매우) 곤란해 질 수 있기에, 팀원 전체의 완벽한 이해와 합의를 통한 convention을 만드는 것이 당장 기능구현을 조금 미루더라도, 우선되어야한다고 생각했다.
처음엔 터미널을 다루는 것이 무섭기까지 했지만, 이제는 머릿속으로 flow 를 그릴 수 있을 만큼 명령어와 개념이 익숙해졌다. 늘 약간의 불안함이 남아있던 git 이었는데, 이제는 확신을 가지고 작업을 할 수 있겠다는 자신감이 생겼다.
convention에 정답은 없다. 자신의 팀과 프로젝트에 최적화된 룰이 있을 뿐. 회의를 통해 우리가 결정한 사안은 다음과 같다.
0. Summary
-
We will use three common branches (release , master , develop) + 1 more branch for back-end
-
We will make branch name by our own name _ (not by feature or function)
: naming by feature(like "feature/login") also seems good enough to us but at this early stage, we decided to keep our branches using our own names. -
We will do PR for merge (especially to develop branch)
-
run the local develop branch once it is update from origin/develop and test it if there are no issues. (daily pull)
- remote 에는 각자의 이름으로 판 브랜치와, dev-master-release 단계로 나누어 코드를 관리하기로 했다.
- 팀이 작은데다가 당분간은 프로젝트의 볼륨이 크지 않을것같아서 feature 별로 branch 를 파는 대신, 각자의 이름으로 작업하기로 했다.
- dev 상태를 최신으로 업데이트 하기위해 daily pull을 생활화하기로 했다.
- 각자의 브랜치에 push 하기 전에도 로컬의 dev가 최신인지를 체크하여 merge 후 push 하는것을 룰로 정했다. (remote에서 conflict 날 때의 번거로움을 막기 위해.)
1. Commit Rules
- Add - 레이아웃 / 기능 추가
- Remove - 내용 삭제 (폴더 / 파일 삭제)
- Modify - 수정 (JSON 데이터 포맷 변경 / 버튼 색깔 변경 / 폰트 변경)
- Style - CSS 수정 (수정시만 사용)
- Fix - 버그/오류 해결 (접속이나 하드웨어 문제일 경우. rarely happened, 웹/앱에서의 호환 차이)
- Refactor - 코드 리팩토링 (스스로 리팩토링 / 중복 코드 제거 / 불필요 코드 제거 / 성능 개선)
- commit title (영어) , message 는 ( 영어 , 한국어 )
- commit title + contents included
- commit title form : [Add] commit message
- 영어를 사용하는 CTO 에릭과의 소통을 최우선으로 하되, 팀원들간의 보다 적확한 소통을 위해 message 는 한/영 혼용하여 사용하기로 했다.
- branch 를 feature 별로 파지 않는 대신 commit title & message에 작업내역을 상세히 명시하여 한눈에 내용을 파악할 수있도록 했다.
- commit format 도 컨벤션으로 정하여 통일성을 주기로 했다.
<느낀점>
- 컨벤션 없이 작업을 했을때는, 롤이 명확히 나뉘지 않아 한 feature를 두 명이 동시에 건드려서 conflict 가 나고, 해결 하는데에도 애를 먹었다. feature 를 정확히 나누는 것의 중요성을 느꼈다.
- 개발은 협업이 더욱 중요하다는 것을 느꼈다. 무언가를 빨리 만들어 내는 것보다 신중하고 천천히 하더라도 문제가 발생하지 않는 것이 결과적으로는 더 빠르다. 엉킨 문제를 해결할 때 팀 전체의 시간과 에너지가 가장 많이 소요된다. (예컨데 git..)
- 명문화의 위대함을 느꼈다. 마치 나라를 세우고 처음으로 헌법을 만드는 기분이었다. 모두가 동의하고 결정된 규칙은 불필요한 논쟁과 미스커뮤니케이션을 줄이는 가장 확실한 방법이다. 깃 룰을 정하고 많은것이 clear 해졌다.
