처음 회사에 신입으로 입사하면 처음으로 마주하는 관문은 회사의 형상 관리 시스템, 쉽게 말해서 branch 운용 전략에 익숙해지는 것입니다. 대표적인 branch 운용 전략으로는 git flow, git-hub flow, git-lab flow 등 다양한 방법론이 존재합니다. 그러나 이러한 방법론을 실제로 사용해볼 경험은 신입으로서 드물었습니다.
입사 전의 저로서는 작게 꾸린 2~3명의 팀으로 프로젝트를 진행해본 것이 협업 경험의 전부였습니다. 기존 프로젝트를 팀원들이 fork한 후에 master branch에 곧바로 pull request를 요청하는 방법이었죠. 그러나 Typed에 입사한 후에는 다른 방식을 사용하고 있어 적응하는데 시간이 필요했습니다.
이 글을 통해서 새로 입사하는 주니어 개발자들 혹은 git 운용 전략을 수립하려는 분들에게 도움이 되었으면 좋겠습니다.
Typed는 어떻게 협업하는가?
1. branch 생성부터 pull request까지
1) 코드의 양이 적은 단일 작업의 경우 : master branch에 곧바로 pull request
예를 들어 hotfix나 작은 디자인 수정의 경우 코드의 양이 적고, 팀원들이 다시 리뷰하기 비교적 쉬운 편이기 때문에 곧바로 master branch에서 checkout한 뒤 master branch에 PR을 보냅니다.
직접 명령어를 작성해보자면 다음과 같은 흐름으로 전개됩니다.
이 과정을 도식화해보자면 다음과 같습니다.
2) 코드의 양이 많은 경우 : feat-base-* branch 로 집합!
대부분 기능 개발은 많은 양의 코드 변화를 가져옵니다. 그러나 한 번에 많은 변경 사항을 올린다면 코드를 리뷰하기가 힘들어집니다.
개발을 작은 단위로 분할하여 각각 리뷰를 한 후에 merge하게 됩니다. 구체적으로는 다음과 같은 순서로 진행되게 됩니다.
- master 에서 base branch 를 feat-base-* 이름 규칙으로 생성하여 push 합니다.
- base branch 로부터 작업 branch를 생성하여 작업합니다.
- 별도의 작업 branch에서 개발이 완료되면 feat-base branch에 merge를 요청하는 PR을 엽니다.
- 모든 작업 branch가 feat-base-*에 merge되었다면, master로 병합을 요청하는 PR을 열거나 곧바로 merge합니다. 이 단계에서 feat-base branch에 대한 리뷰는 일반적으로는 필요하지 않습니다. 작업 branch 단에서 이미 변경 사항이 리뷰되었기 때문입니다.
2. 코드 리뷰를 거쳐 merge 되기 까지
1) 코드 리뷰 받기
Pull Request를 요청한 후에는 팀원들 간의 리뷰를 통과해야 합니다.이 과정에서 팀원들에게 자신의 코드를 명확하게 설명할 수 있어야 하고 때로는 자신의 코드를 변호할 줄도 알아야 합니다. 만약 더 좋은 방법을 팀원이 제시하였거나, 명확하게 틀린 부분을 지적한 경우 수용하여 다시 리뷰 요청을 보내는 것이 좋습니다. 이 과정에서 더 나은 퀄리티의 코드를 위한 것이라 감수하고 ego를 내려놓을 필요가 있습니다. 이게 다 좋은 제품을 만들기 위한 것이니까요!
코드 리뷰의 예시는 다음과 같습니다.
팀원들이 리뷰를 마치고 해당 부분을 수정한 후에는 merge 되어도 좋다는 승인(approve)를 합니다. Typed에서는 2명 이상의 팀원이 승인한 경우 merge할 수 있도록 정해두었습니다.
merge할 수 있는 권한을 획득하였다면 master branch 혹은 feat-base-* branch에 Squash and merge합니다.
Squash and merge란 branch의 commit 내역을 squash, 즉, 뭉뚱그려 하나의 commit으로 만들어 merge하는 것입니다. Squash and merge된 내역들을 살펴보면 병합된 branch의 commit의 양과 관계 없이 하나의 commit으로 정리된 것을 확인할 수 있습니다.
Typed의 경우 master branch에 merge된 순간, github action를 통해 자동으로 staging 배포를 진행됩니다. staging 단계에서는 QA가 진행됩니다. 이후의 개발 프로세스는 다른 글에서 살펴보도록 하겠습니다 🙂
2) 코드 리뷰 해주기
프로젝트에 참여하는 개발자는 reviewee이자 reviewer이기도 합니다. 코드 퀄리티 향상과 프로덕트의 코드 이해를 위해 다른 팀원의 코드를 리뷰할 필요가 있습니다. 저 같은 신입 개발자의 경우에는 기존에 입사하신 분들의 코드를 보고 학습할 수 있는 추가적인 효과도 있습니다.
그러나 무엇보다 리뷰를 해야 하는 가장 큰 이유는 리뷰를 통과하지 못하면 merge될 수 없다는 것입니다. 자신의 일이 급한 만큼 다른 팀원의 일도 급하다는 것을 인정하고 성실하게 코드 리뷰를 해줄 필요가 있습니다.
아래와 같은 pull request 요청이 왔다고 가정하겠습니다.
우리는 feat-bulk-resource-reorder-service branch에 올라온 코드를 확인하고 실행시킬 필요가 있습니다. 다른 branch로 스위칭하기 전 현재 작업한 사항을 commit해도 되지만, 완료하지 않은 작업을 commit 하기에는 찜찜함이 있습니다. git stash를 통해서 현재 작업 사항을 임시 저장한 후 checkout하도록 합시다.
리뷰는 아래와 같이 진행됩니다.
기존 코드와 변경된 코드를 확인하면서 의문이 가는 부분, 개선할 여지가 있는 부분을 marking하고 기록을 남깁니다.
리뷰를 통과하여 해당 코드를 merge해도 된다는 판단이 서면 승인(Approve)을 하게 됩니다.
3. 그 밖의 팁
1) git diff –stat
Typed에선 코드 리뷰가 힘들지 않도록 한 PR당 변경 사항이 500 줄을 넘지 않도록 hard rule을 정했습니다. 그런데 지금까지 자신이 한 작업이 master 혹은 feat-base-* 와 얼마나 다른지를 짐작하기란 어렵습니다.
얼마나 달라졌는지 체크하기 위해서 git diff를 활용하면 편리합니다.
2) git log
branch를 오고 가며 작업하면 현재 자신이 어느 branch의 어느 commit에 있는지 가시적으로 확인하기 어려울 때가 있습니다. 이럴 때는 git의 내역을 시각적으로 확인하고 편리하게 관리하기 위해 sourceTree, git kraken와 같은 gui 툴을 사용하곤 합니다.
그러나 별도의 툴 설치 없이 간단하게 git log 만으로도 git graph를 확인할 수 있습니다.
명령어가 꽤 길기 때문에 alias로 등록해놓고 사용하면 편합니다.
이제 git graph라는 커스텀 명령어를 사용할 수 있게 되었습니다.
글을 마치며
Typed는 위에 언급한 사항 외에도 다양한 방법으로 코드를 관리하고 있습니다.
대표적으로, 디자인 팀과 원활한 작업을 위해서 특정한 이름 규칙을 만족하는 branch로 PR을 올리면 github action에 의해 자동으로 preview 배포가 진행됩니다. 실제로 배포된 화면을 보고 검수할 수 있기 때문에 보다 편리하고 정확하게 UI 관련 이슈들을 처리할 수 있습니다.
Typed가 이러한 branch 운용 전략과 코드 관리 체계 방식을 수립하게 된 것은 프로젝트의 성격과 구성원 규모 등이 고려된 결과입니다. 예를 들어 git flow를 엄격히 지키려면 사소한 변경 사항도 master에 반영되기까지 branch switching이 자주 일어나야 하는데, agile한 개발, 배포 환경을 추구하는 현재 Typed와는 거리가 있었습니다. 따라서 Typed의 개발 환경은 현 상황에 따라 결정된 환경이며, 개발 환경이 변한다면 언제든지 바뀔 수 있습니다.
저희 Typed와 함께 빠르게 성장하면서 개발 문화에 대해 고민하고 개선해 나가고 싶으신 분은 Typed에 지원해주세요!
Suhun / Front Engineer
팀 타입드에 합류하고 싶다면?
타입드 제품 먼저 보고 싶다면?
