[외주]협업 전 규칙 정리하기 (Convention) - 에이젠

추석 연휴에 짬내서 외주 프로젝트의 gitLab 레포지토리를 훑어보았습니다.

일단 아키텍쳐, 기술스택 등은 회사에서 정해준 템플릿대로 구현해야했기에
도전해볼만한 or 적용해보고 싶은 부분은 따로 생각할 필요가 없었습니다.

 

외주 프로젝트에 투입되기 전 작업하고 계셨던 iOS개발자는 한분이셨습니다.

제가 투입된 시점부터 저를 포함해 두명이서 작업을 하게 될 예정입니다.

 

두명이 되었으니 서로 코드리뷰를 하면서 작업할 수 있고
충돌방지에 신경을 써야할테죠.
안정적인 version관리를 위해서 네이밍, Commit 컨벤션, Branch 전략 등의 필요성을 느꼈습니다.
(이전 DND 사이드 프로젝트에서 경험한 협업에서 처음 적용해보았습니다.)

 

최근 심사를 통과한 Bidit앱은 iOS를 혼자 맡아서 진행중이기에 충돌문제나 브랜치 전략에 크게 의미를 두지 않았습니다.

깃허브 레포지토리를 관리하면서 실수들이 나올 때 제 스스로에게 많이 관대했던 것 같습니다. ㅎㅎㅎㅎㅎ

다시 처음부터 자주 사용하는 것들과 필요한 부분들만 간단하게 정리해보려고합니다.

 

깃 사용시 주로 사용하는 커맨드

ls : 파일목록 (window -> dir)

cd  : 이동

cd .. : 빠져나가기

 

주의 ) add 하기전 pull 안 하면 꼬임.

git add -A 모든 파일 add

git branch : 브랜치 리스트 조회

git branch eigen eigen이라는 브랜치 생성(eigen이라는 예시)

git checkout eigen eigen브랜치로 변경

 

-> 해당 브랜치에서 수정 된 파일 add 

-> commit

-> eigen 브랜치로 push

 

 main브랜치로 merge하려면? 

git checkout main main브랜치로 변경

git merge eigen eigen소스를 main에 반영(로컬)

git push origin main

 

git branch -d eigen eigen 브랜치 삭제

 

브랜치 전략

gitFlow 전략 :
master(출시), develop(출시 전 개발), feature(기능 구현), release(출시 전 테스트), hotfix(출시 버전 수정)
다섯가지 브랜치로 나누어 관리하는 방법입니다. 설명은 아래 링크에 자세히 나와있습니다.

 

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

Trunk-based 전략 : 브랜치 하나만 잘 관리하는 방법입니다.

이전 개발자께서 작업해주신 부분이 적지 않은 양이었고

또한 두명이므로 오히려 브랜치를 늘리고 규칙을 많이 만들수록 효율이 떨어질 수 있다고 생각하였습니다.

혼란이 없도록 크게 달라지지 않도록 간단하게 정리하였습니다.

이슈 발행 및 관리는 따로 커뮤니케이션 시트가 있기때문에 추가할 필요가 없다고 판단하였습니다.

✏️ Commit Convention

Head(필수)

1. 기능을 태그로 작성한다.
2. 설명은 수정한 내용을 알아보기 쉽고 간단하게 작성. Tag : Feat(구현), Fix(수정), Chore(주석)

ex) [Feat] Add no review screen

Body (선택)

1. '어떻게' 변경했는지 보다 '무엇을', '왜' 변경했는지 작성 (방법보다 사유 기술)

Tail(Optional) : 작성 X

🌿 Branch 전략 ⇒ Trunk-based

브랜치 카테고리

• main : 제품으로 출시될 수 있는 브랜치
• feature : 기능을 개발하는 브랜치 네이밍 : feature/{feature name} ex. feature/login 해당 기능 구현시 상의 후 브랜치 제거