[개발] 협업 준비

이진규·2022년 12월 13일
1

1. 브랜칭 전략

① Git-flow

Git-flow는 총 5가지의 브랜치를 사용해서 운영

  • master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
  • develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
  • feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
  • release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
  • hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보시면 됩니다.

② Git-flow 진행흐름

  1. 일단 master 브랜치에서 시작을 합니다.

  2. 동일한 브랜치를 develop에도 생성을 합니다. 개발자들은 이 develop 브랜치에서 개발을 진행합니다.

  3. 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합니다.

  4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합칩니다.(Merge)

  5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스합니다.

  6. 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다.

  7. 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.

branch 를 merge 할 때는 항상 --no-ff 옵션을 붙여서 branch 에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 합니다.

③ Pull request와 코드 리뷰

https://www.youtube.com/watch?v=9FZaYz0s8s4

2. 커밋 컨벤션

커밋 메시지를 작성할 때는 원칙을 정하고 일관성 있게 작성해야한다.
그래서 Udacity 커밋 메시지 스타일 가이드를 기준으로 커밋 메시지 스타일을 정하기로 한다.

① 커밋 메시지 구조

기본적으로 커밋 메시지는 아래와 같이 제목/본문/꼬리말로 구성된다.

type : subject - 제목

body - 본문

footer - 꼬리말

실제 예시)

Feat: "회원 가입 기능 구현"

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

①-1 제목

제목은 타입(type)과 주제(subject)로 구성된다.
타입 : 주제의 형태이며, : 뒤에만 space가 있음에 유의한다.

타입(type)
타입은 영어로 쓰되 첫 문자는 대문자로 한다.

Feat : 새로운 기능 추가
Fix : 버그 수정
Docs : 문서 수정
Style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
Refactor : 코드 리펙토링
Test : 테스트 코드, 리펙토링 테스트 코드 추가
Chore : 빌드 업무 수정, 패키지 매니저 수정

주제(subject)

  • 주제는 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
  • 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다. (과거 시제를 사용하지 않는다.)
Fixed --> Fix
Added --> Add
Modified --> Modify
  • 주제는 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미.

①-2 본문

본문은 다음의 규칙을 지킨다.

  • 본문은 한 줄 당 72자 내로 작성한다.
  • 본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
  • 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.

①-3 꼬리말

꼬릿말은 다음의 규칙을 지킨다.

  • 꼬리말은 optional이고 이슈 트래커 ID를 작성한다.
  • 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.
  • 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
  • 이슈 트래커 유형은 다음 중 하나를 사용한다.
    • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
    • Resolves: 이슈를 해결했을 때 사용
    • Ref: 참고할 이슈가 있을 때 사용
    • Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
      ex) Fixes: #45 Related to: #34, #23

② 커밋 메시지 이모지

커밋 메시지를 이용할 때 이모지를 이용하면 내용을 한 눈에 파악하기 쉽기 때문에 이용한다.

EmogiDescription
🎨코드의 형식 / 구조를 개선 할 때
📰새 파일을 만들 때
📝사소한 코드 또는 언어를 변경할 때
🐎성능을 향상시킬 때
📚문서를 쓸 때
🐛버그 reporting할 때, @FIXME 주석 태그 삽입
🚑버그를 고칠 때
🔥코드 또는 파일 제거할 때 , @CHANGED주석 태그와 함께
🚜파일 구조를 변경할 때 . 🎨과 함께 사용
🔨코드를 리팩토링 할 때
💄UI / style 개선시
♿️접근성을 향상시킬 때
🚧WIP (진행중인 작업)에 커밋, @REVIEW주석 태그와 함께 사용
💎New Release
🔖버전 태그
새로운 기능을 소개 할 때
⚡️도입 할 때 이전 버전과 호환되지 않는 특징, @CHANGED주석 태그 사용
💡새로운 아이디어, @IDEA주석 태그
🚀배포 / 개발 작업 과 관련된 모든 것

3. 코딩 컨벤션

코딩 컨벤션이란 가독성이 좋고 관리하기 쉬운 코드를 작성하기 위한 코딩 스타일 규약을 말한다.

코딩 컨벤션을 준수하면 가독성이 좋아지고 성능에 영향을 주거나 오류를 발생시키는 잠재적인 위험 요소를 줄여줘 유지보수 비용을 줄일 수 있다.

Java에서는 구글이나, 네이버에서 지정한 코딩 컨벤션이 유명하며, 이번 프로젝트에서 네이버 코딩 컨벤션을 이용하여 진행하도록 한다.

밑의 [4. 기타설정 ③ IntelliJ에서 포맷터 적용 설정]을 참고하여 Code Style Formatter를 설정하고, Checkstyle까지 적용하면 된다.

그리고 아무리 포맷터가 컨벤션을 지켜준다 하더라도 컨벤션 규칙에 대한 것은 인지하고 있어야 하기 때문에 네이버 코딩 컨벤션에 대한 자세한 내용은 다음 링크를 참조하여 코드를 작성하도록 한다.

4. 패키지 구조

5. 스웨거 설정

6. 기타설정

① IntelliJ에서 pull request 설정

깃허브에서 직접 pull request 하지 않고 간단하게 인텔리제이에서 할 수 있는 방법

Third-party application access policy 에 대한 접근 제한 이슈 발생

  1. 내 프로필 클릭하여 Your organizations 클릭

  2. 현재 참여중인 팀 프로젝트 목록이 뜨면 Settings 클릭

  3. 왼쪽 하단에 OAuth application policy 클릭

  4. 타사 애플리케이션 제한 해제를 위해 Remove restrictions 클릭

위의 과정을 하게 되면 다음과 같이 인텔리제이(Intellij) 에서 pull request를 할 수 있도록 연결이 되게 된다.

② IntelliJ에서 Commit Message Emoji 설정

매번 코드를 외워서 쓰거나 복사해 놓은 코드를 붙여넣는건 귀찮기 때문에 IntelliJ에 플러그인을 붙여서 사용

  1. Shift를 두번 눌러서 Plugins 검색 후 클릭

  1. Marketplace를 선택하고 gitmoji를 검색하여 설치

  1. 인텔리제이 커밋창으로 돌아가서 다음 빨간색 박스에 이모티콘이 뜨면 성공

③ IntelliJ에서 포맷터 적용 설정

코딩 컨벤션을 모두 기억하고 매번 맞춰가며 개발하기 쉽지 않을 것이다. 이런 문제를 해결하기 위해 코딩 컨벤션은 포맷터를 이용하여 더 쉽게 코딩 컨벤션을 적용할 수 있다.

  1. 위 링크에서 IntelliJ용 XML 포맷터를 다운로드 받는다.
    -> Raw 버튼 클릭 후 Ctrl+S 눌러서 저장하면 됨

  2. IntelliJ를 키고 [File] - [Settings] - [Editor] - [Code Style]로 가서 Scheme 우측 톱니바퀴 클릭 후 [Import Scheme] - [IntelliJ IDEA code style XML] 클릭

  3. 다운로드 받은 XML 포맷터를 찾아 설정하면 된다.

위의 과정을 모두 끝냈으면 코드 입력 후 단축키만 누르면 포맷터가 적용되어 코드 컨벤션을 지킬 수 있게 된다.

  • 윈도우 : Ctrl + Alt + L
  • 맥 : Cmd + Alt + L

포맷터 적용 전

포맷터 적용 후(Naver 자바 컨벤션)

④ IntelliJ에서 저장시 마다 코딩 컨벤션 자동 적용할 수 있도록 설정

위 과정을 완료하면 Code Style Formatter 설정이 끝난다.

소스코드 또는 패키지나 프로젝트 디렉터리를 선택 한후 Ctrl + Alt + L 을 누르면 지정한 코드 스타일에 맞게 자동으로 코드에 포멧터가 적용된다.

그러나 일일히 이렇게 단축키를 눌러가며 적용하는건 귀찮기도 하고 깜빡할 위험이 있다. 그렇기 때문에 저장할 때마다 포멧터를 자동으로 적용하는 설정을 추가하도록 한다.

  1. [File] - [Settings] - [Tools] - [Actions on Save]로 이동한다

  2. Reformat code(저장 시 자동으로 포맷 적용)와 Optimize imports(저장 시 사용하지 않는 import 제거)를 체크한다.

⑤ IntelliJ에서 CheckStyle 적용 설정

Checkstyle이란 Java 소스 코드가 지정된 코딩 컨벤션을 준수하는지 확인하기 위한 정적 코드 분석 도구이다. 지정된 규칙에 어긋나는 경우 컴파일 시 경고나 에러를 띄워준다.

naver-checkstyle-rules.xml
naver-checkstyle-suppressions.xml

  1. [File] - [Settings] - [Plugins]으로 이동하여 Marketplace에 CheckStyle을 검색하여 CheckStyle-IDEA 플러그인을 설치하고 IntelliJ를 재시작한다.

  2. File → Settings → Tools에서 Checkstyle 항목을 선택한다.

  3. Scan scope를 All sources including tests로 설정한다.

  4. Treat Checkstyle errors as warnings를 체크한다.

  5. Configuration File에서 + 버튼을 클릭한다.

  6. Description은 Naver Checkstyle Rules [버전] 으로 지정하는 것이 권장되지만 프로젝트별로 커스터마이징 했다면 프로젝트 이름 등을 붙인다.

  7. Use a Local Checkstyle File을 선택하고 Browse 버튼을 눌러서 naver- checkstyle-rules.xml를 지정하고 Next 버튼을 누른다.

  8. suppressionFile 변수를 설정하라는 창이 뜨면 Value에 naver-checkstyle-suppressions.xml를 입력하고 Next 버튼을 누른다.

  9. Naver Checkstyle Rules의 Active를 체크한다.

Ok 버튼을 눌러 설정을 완료하면, InteliJ 하단에 Check Style 탭이 생기고 좌측에서 Check Current File 또는 Check Module, Check Project 등을 선택하여 코딩 컨벤션 준수 여부를 확인할 수 있다.

변수명에 소문자 카멜 케이스를 적용해야 한다는 컨벤션을 지키지 않자 CheckStyle에서 경고를 띄워주는 모습을 확인할 수 있다.

7. 참고자료

profile
항상 궁금해하고 공부하고 기록하자.

0개의 댓글