할때마다 commit 하라고 해서,
git add .
git commit -m
기능별로 commit을 하라는건, push까지 해야 한다는 뜻.
m
pr: 큰 기능에, feature branch의 마감
commit message에 어떤 기능별로 오면, 그거만 보면 되는데,
한번에 보면 보는 사람이 피곤함. 132줄 짜리 코드를
우선, signup branch
push
pull request 버튼을 누르면,
4가지를 체크해야 한다.
1. base 위치 / compare branch
2. reviewers
3. assignees
4. commit 내역
1. branch 설정 잘 돼 있는지
우리 팀은 바로 main에 merge 하지 않고,
dev에 하기로 했다.
main 은 정말 최종의 깔끔한 코드만 갈 수 있도록, 중간 장치로 dev를 만들어놓았다.
(base: dev, compare: feature signup)
dev에 하지 않고, main에 할 경우,
edit으로 이후에 수정 가능.
리뷰어들이 comment로 base 위치도 확인해줄 것이기에.
2. reviewers (reviewer들도 코드에 대한 책임을 나눠가지는 것)
내가 올린 pr의 코드들을 리뷰하고 코멘트 달거나,
괜찮으면 패스 할 팀원들/ 매니저를 태그
reviewers 버튼을 클릭하면 list가 뜬다.
검색 가능
3. Assignees-> 나 자신을 하는 것
- assign yourself를 누르면 나 자신으로 된다.
4. commit 제목도 중요하다.
초보 개발자들은 이 중요성을 모르고 대충 설정하는데,
다른 개발자들이 참고할 수 있도록
상세하게 적어주는 것이 중요하다.
여기에 쓰는 comments는 "pull requests template.md" pull request 하기 전에
깃허브에서 작성하는 것.
vscode에 있는 "pull requests template.md" 는 디폴트 값.
말그대로 template이다.
만약 vscode에 적고 push 후 추후에 팀원들과 merge하면
내 것이 그대로 합쳐져서 안 됨.
그리고 나의 branch에서 pull request 할 때 작성되는 것이기에,
다른 사람들의 "pull requests template.md" 에 올라가는 것은 아니다
이렇게 설정 후
pr을 하면, 백엔드 팀원들에게 알람이 간다.
메일로도 가고, 채널 슬랙에 알람이 간다.
깃허브랑 슬랙이랑 연동돼서, 이렇게 올라온다.
리뷰만 하는게 아니라.
이거 정말 잘하셨더 어떠헥 하셨냐
코드를 같이 보는 것.
늦게할 수록 손해,
push 전에도
내가 아침에 dev에서 pull을 했더라도, push를 할 시점에 다른 사람이 수정해서 pull 했을 수도,
dev에서 pull을 하고 해야
conflict 예방해서, 나중에 Merge 후에 conflict로 다른 사람 코드 보며 비교할 게 적어짐
'Wecode - Project 2 (부트캠프) > Project 2 과정' 카테고리의 다른 글
| Project 2 - 5일 차 (5): 내가 push 한 회원가입 함수 : standing meeting에서 수정할 부분 (0) | 2023.09.22 |
|---|---|
| Project 2 - 5일 차 (4): standing meeting- [프론트 엔드와 협의] 및 [회원가입 코드 분석] (0) | 2023.09.22 |
| Project 2- 5일차 (1): 내가 짠 [회원가입 API 및 설명] (0) | 2023.09.22 |
| Project 2 - 4일차 (5): [상세페이지 기능 구현] (0) | 2023.09.21 |
| Project 2 - 4일차 (4): [상품 목록 페이지 기능 구현] 구조화 ** (0) | 2023.09.21 |