일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- adb pair
- github 100mb
- animation
- camera permission
- 티스토리 성능
- adb connect
- react-native-dotenv
- nextjs
- Recoil
- Each child in a list should have a unique "key" prop.
- 이미지 데이터 타입
- dvh
- Git
- silent printing
- rolldown
- vercel git lfs
- Failed to compiled
- Can't resolve
- html
- github pdf
- camera access
- ELECTRON
- react-native
- npm package
- custom printing
- augmentedDevice
- device in use
- github lfs
- electron-packager
- ffi-napi
- Today
- Total
Bleeding edge
협업을 위한 PR 가이드라인 및 용어 정리 본문
개요
최근에 회사에 동료들이 늘어나면서, 이전과 같게 진행하면 문제가 생길 것 같아서, PR 가이드라인을 작성하고 컨벤션을 위하여 자동화를 세팅하기로 했다.
PR 작성 가이드 라인
1. 코드 변경은 작게 작성 (LOC(Line of codes)는 400줄 이내로 작성)
2. 버그 하나당 하나의 PR
3. 버전 업데이트 및 리팩토링은 별도의 PR로 관리
4. 규모가 큰 변경 사항은 의미(semantic) 단위로 분리
5. 맥락을 이해할 수 있는 정보를 PR에 담기(내용에는 어떤 코드인지보다 왜 이 코드를 작성했는지가 중요)
PR 내용 가이드라인(template를 만드는 것도 좋다)
1. 이 PR은 어떤 PR인지
2. 이게 왜 필요한지(Optional)
3. 어떻게 구현했는지
4. 어떻게 테스트 할 수 있는지(상시 확인가능하면 Optional)
5. 이해하기 위한 스크린샷(Optional)
6. 어떻게 재연할 수 있는지(Optional)
PR 리뷰 가이드 라인
1. 너무 사소한 코드는 자동화로 해결(formatting 같은 것은 자동화로)
2. 수정에 대해서는 이유와 대안/추천하는 것을 제안
3. 일반적인 방식 보다는 구체적인 피드백을 제안하기
4. comment에 대한 가이드라인
[질문]: 코드에 대한 질문(비판이 아닌 질문)
[마이너]: 이렇게 하면 좋을 것 같다. but 그렇게 큰 요구사항이 아니다.
[변경]: 이걸 꼭 수정해야한다. 이것을 수정하지 않으면 승인하지 않겠다.
예시1) [마이너]이 코드는 가독성이 좋지 않으니 이 부분은 -와 같이 작성하는 게 저 좋을 것 같아요
예시2) [질문]이 부분은 이러한 이유 때문에 작성한 것 같은데 맞나요?
5. 리뷰 완료에 대한 기준점
승인: 전체 방향성 ok 작은 변경요청
변경 : 이대로 배포 불가 코드수정 필요
질문 : 코드 의도 파악 큰그림의 질문 설계적인 질문
용어 정리(자주 쓸 것 같은 것은 파란색으로 처리했다.)
NIT (nit pick): 중요하지는 않지만 더 나은 방법이 있다 혹은, 아주 작은 디테일이라는 뜻
예시: (NIT: removed whitespace)
ACK (Acknowledgement): 승인을 남길 때 사용한다. 어디까지 확인했는지 승인을 하는건지 남기고 싶을 때는 다음과 같이 작성한다.
Concept ACK
아이디어와 전반적인 방향에 대해 동의는 하는데, 코드를 확인하거나 테스트를 해보진 않았다.
utACK (Untested ACK)
코드를 확인은 했는데 테스트는 안 했다.
tested ACK
변경사항에도 동의하고, 검토도 했고, 테스트도 했다.
NACK/NAK (Negative Acknowledgement): 승인을 거절할 때 사용한다. 거절할 때는 왜 거절했는지에 대한 이유를 함께 적어야 한다.
RFC (Request For Comments): 의견을 요청할 때 사용한다.
WIP (Work In Progress): 작업이 아직 진행 중으로, 병합하지 않았을 때 사용한다.
AFAIK/AFAICT (As Far As I Know / As Far As I Can Tell): 내가 아는 한.. / 내가 말할 수 있는 건.. 어떤 의견을 낼 때 앞에 접두어처럼 사용한다.
IMO (I My Opinion): 개인적인 의견이지만.. 어떤 의견을 낼 때 앞에 접두어처럼 사용한다.
FYI (For Your Information): 직역하면 당신의 정보를 위해서, 의역하면 참고로라는 뜻이다. 상대가 알아야 하는 내용을 전달할 때 사용하며, FYI 다음에는 어떤 주제에 대한 정보가 온다. 비슷한 말로 FYR (For Your Reference) 알아두면 도움이 될 것이다 라는 말도 있다.
PTAL (Please Take a Look): 이거 좀 확인해주세요, 봐주세요.
SSIA (Subject Says It All): 타이틀만 봐도 전부 이해할 수 있다.
TBD (To Be Determined):당장 결정하기는 힘들지만, 곧 결정할 것이라는 뜻이다.
TL;DR (Too Long; Didn't Read): 너무 길어서 안 읽었다.
PR 가이드라인 출처 : https://www.youtube.com/watch?v=bUY3wNjcVMk
용어정리 출처 : https://yoon-jj.tistory.com/10
'Git & Github' 카테고리의 다른 글
여러 커밋 합치기[링크] (0) | 2023.06.18 |
---|---|
yarn install --frozen-lockfile 에러 해결하기 (0) | 2023.06.18 |
rebase and merge버튼이 비활성화 해결 방법[링크] (0) | 2023.06.16 |
git push origin current-branch (0) | 2023.02.15 |
Pull request 로컬로 쉽게 가져오기! (0) | 2023.01.18 |