Github 협업 전략

브랜치 전략

• 저희팀은 기본적으로 git flow를 따르되 release 브랜치의 경우 현재 상황에서는 필요없다고 판단하여 제외하고 main, develop, feature, hotfix 브랜치만 사용합니다.

• main - 최종 배포 브랜치입니다.

• develop - 배포 전 모든 기능 개발 및 수정 사항을 해당 브랜치로 Merge 합니다.

• feature - 기능 개발 브랜치입니다.

• hotfix - 최종 배포 버전에서 발생한 버그를 수정 하는 브랜치입니다.

• 브랜치간 merge 전략은 다음 규칙을 따릅니다.
• develop → main : crate a merge commit 옵션 사용 ( 이때, 태그를 추가하게 됩니다. )
• feature → develop : squash and merge 옵션 사용
• develop → feature : rebase and merge 옵션 사용

• Jira를 사용하기 때문에 이슈ID를 사용하여 작업합니다.
• 예) feat/WOOR-1
 

커밋 컨벤션

[WOOR-1] feat: 회원 로그인 api 구현

• feat : 새로운 기능 추가

• fix : 버그 수정

• style : 코드 포맷팅, 세미클론 누락, 코드 변경이 없는 경우

• refactor : 코드 리팩토링

• test : 테스트 코드, 리팩토링 테스트 코드 추가

• docs : 문서 수정

• chore : 빌드 업무 수정, 패키지 매니저 수정 및 그 외의 작업

PR & 코드리뷰

[WOOR-1] feat: 회원 로그인 API 구현

• PR이 올라오면, 리뷰어를 할당하고 한명 이상의 approve가 있어야 merge할 수 있습니다.
• 리뷰어는 24시간안에 리뷰를 수행해야합니다.

• PR을 올린 담당자가 리뷰를 통해 수정을 마쳤을 때 merge 합니다.

깃허브 설정

GitHub

헤이딜러 개발팀 모두가 행복한 개발/PR관리 방법 7가지

개발자마다 코딩하는 방식은 제각각입니다. 똑같은 if/else문을 작성하더라도 각자의 방식대로 코딩합니다.😱 vs name을 표시하는 TextView라는 UI의 id를 정할때도 등으로 자기가 맘에드는것으로 선택해서 정합니다. 혼자 개발할때는 문제가 없지만 여러명이 하나의 프로젝트를 개발할때는 각자 다른 방식으로 코딩하는것이 문제가 됩니다. 그래서 코딩 컨벤션📝이 필요합니다.코딩 컨벤션을 만들고 이를 모두가 지켜서 코딩한다면 아래와 같은 점이 좋습니다.

https://medium.com/prnd/%ED%97%A4%EC%9D%B4%EB%94%9C%EB%9F%AC-%EA%B0%9C%EB%B0%9C%ED%8C%80-%EB%AA%A8%EB%91%90%EA%B0%80-%ED%96%89%EB%B3%B5%ED%95%9C-%EA%B0%9C%EB%B0%9C-pr%EA%B4%80%EB%A6%AC-%EB%B0%A9%EB%B2%95-7%EA%B0%80%EC%A7%80-1d4cd5d091f0

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

안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합니다. '배달의민족 안드로이드 모바일 파트에서 이렇게 브랜치를 관리하고 있구나' 정도로 봐주시면 좋을 것 같습니다. 2016년 1월, Github로 소스코드를 이전하면서 Github-flow를 사용하기 시작했습니다. 그러다 2017년 6월부터 Git-flow로 브랜치 전략을 바꾸게 되었습니다.

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