Branch Rule Setting
1. Branch name pattern
특정한 브랜치나 특정한 패턴을 가진 브랜치에 대해 Branch Protection Rule이 적용될 수 있도록 한다.
main : main브렌치에만 적용|
feat/* : ‘feat/’으로 시작하는 모든 브랜치에 적용
* : 모든 브랜치에 적용
2. Protect matching branches
1. Require a pull request before merging (이 방식을 채택!)
상세설명
2. Require status checks to pass before merging (충돌을 막기위해 자주 쓰이는 방식입니다.)(채택!)
상세설명
3. Require conversation resolution before merging
상세설명
4. Require signed commits
상세설명
5. Require linear history
상세설명
6. Require deployments to succeed before merging
상세설명
7. Lock branch
상세설명
8. Do not allow bypassing the above settings
상세설명
3. Rules applied to everyone including administrators (왠만하면 사용금지)
1. Allow force pushed
상세설명
2. Allow deletions
상세설명
Setting 완료화면
팀원 추가하기
팀장이 초대 메일을 보내면 승인하면 팀원으로 등록이 된다.
작업하고 커밋하기
개발 환경세팅을 작업해서 올린다.
→ push를 하면 아래 그림과 같이 Compare & pull request창이 뜬다.
처음 세팅 하는 방법
$ touch 환경세팅.txt
$ git add .
$ git commit -m "1.세팅 완료"
# dev 브랜치 생성하고 push하기
$ git checkout -b dev
# 모든 브랜치 푸시
$ git push --all
Swift
복사
작업후 push하는 방법
→ 브랜치를 파고 작업을 해야합니다!!
//브랜치 생성 -> git branch를 해서 이동이 잘 됐는지 확인해 주세요.
git checkout -b [사용할 브랜치 이름]
//branch를 이동 하기 위한 방법
git switch [브랜치 이름]
//push 하는 방법
git push origin [브랜치 이름]
Swift
복사
Pull Request 작성방법
초기 프로젝트생성시
이후 작업시
•
저희에게 맞는거 같은 Tool을 만들어보았습니다.
•
혹시 다른 추가하고 싶은게 있으면 말씀해 주세요!!
커밋 메세지의 기본 구성은 title, body, footer로 구분됩니다. Title은 반드시 작성해야 하고, body와 footer는 상황에 따라서 작성하면 됩니다.
type 이모지: Subject
body
footer
Plain Text
복사
•
"깃모지 + 설명" 형태로 작성 ex)
프로젝트 세팅
•
영어로 작성 시 대문자로 동사형태로 시작합니다.
•
.금지
•
50글자 이내로 작성합니다.
•
feat / refactor / design을 사용해 봅시다.
깃모지 | 태그 | 설명 |
feat | 새로운 기능을 추가 | |
fix | 버그를 수정 | |
refactor | Production 코드 리펙토링 | |
test | Test를 추가, Test 코드 리펙토링 (production code에는 변경이 없음) | |
design | UI 디자인 변경 | |
rename | 파일 이름 변경 및 폴더 변경 | |
remove | 파일 삭제 | |
docs | documetation을 변경 | |
style | Formatting, 세미콜론 추가 (code에는 변경이 없음) | |
chore | Build task를 업데이트, package manager 설정 (production code에는 변경이 없음) | |
comment | 주석을 추가하거나 삭제했을때 | |
add | 새 파일 추가 | |
개발 스크립트 추가/수정 | ||
술 취해서 쓴 코드 | ||
똥 싼 코드 |
•
작업에 대한 상세설명을 적지만 필수는 아닙니다.
•
변경사항에 대해 왜 변경했는지 작성합니다.
•
title과 한 줄 띄워서 작성하여야 가독성이 좋아집니다.
•
영문으로 작성할 경우 72글자를 기준으로 작성합니다.
•
필수 요소가 아닙니다.
•
해결된 이슈와 참고한 레퍼런스 이슈를 첨부합니다.
•
body와 한 줄 띄워서 작성하여야 가독성이 좋아집니다.
각자 라벨지 만들기 (만들어 주세요!!)
참고 자료
pull request 완료 화면
코드리뷰
•
초록색 화면이 변경된 부분을 나타냅니다.
•
화면의 메시지 창을 클릭하면 글을 남길 수 있습니다.
* 코드에 이상이 없다면 Finish your review에 글을 간단하게 작성하고 Approve를 누르면 됩니다.
코드리뷰 문화
•
코드리뷰를 잘 하는것이 진정한 개발자라고 합니다.. 한번 쭉 읽어보시면 도움이 많이 될꺼에요!!