개인마다 혹은 팀마다 깃허브로 협업하는 방식은 다르겠지만
제가 하는 방식을 정리해보겠습니다.
아래는 collaborator로 조인한 상황이라고 가정 후 작성하겠습니다.
자신이 사용하는 editor에서 프로젝트를 다운 받을 곳에
git clone (원격 레포)
git clone https://github.com/TaehwanGo/inflearn-clone-back.git
npm ci
로 필요한 패키지들을 설치
npm run start
앱 실행
(진행 중인 project가 있다는 가정 하에)
새로운 이슈 등록하기
4-1. 브랜치 생성
git checkout -b 브랜치이름
브랜치 이름은 작업할 내용과 관련있게 지으면 좋겠습니다.
ex) git checkout -b login/api
작업이 끝나고 코드를 반영할 준비가 되었다면
git add .
현재 까지 작업 한 내용을 git에 저장합니다.
git commit -m "작업내용"
commit message에 작업내용은 아래 링크를 참고해서 작성합니다.
https://beomseok95.tistory.com/328
master(또는 main) branch에는 아래와 같은 룰이 설정되어 있어 바로 push를 하지 못 합니다.
(branch rule은 팀마다 다를 수 있습니다.)
git push origin 브랜치이름
원격 레포지토리에 push를 합니다.
이때 원격 레포에 새로운 브랜치가 생성됩니다.
github로 와서 pull request를 요청합니다.
이때 리뷰어를 선택 할 수 있습니다.
코드리뷰는 계약서에 사인한다고 생각하신다는 마음으로 한줄 한줄 꼼꼼히 리뷰를 합니다.
pull request(코드리뷰)를 요청받았다면 가장 최우선순위라고 생각해주시면 좋겠습니다.
코드리뷰에 코멘트를 남길 땐 '칭찬' | '질문' | '의견' 중 하나를 남긴다고 생각하시면 됩니다.
이해가 안되면 질문을 하시면되고 코드에 대해 다른 의견이 있으면 의견을 자유롭게 남기셔도 되고 다 좋아서 남길 코멘트가 없으면 칭찬이라도 남기면 좋을 것 같습니다.
수정해야될 부분이 있으면 수정될 때까지 pull request요청 받은 것을 approve 않고 지연할 수도 있습니다.
리뷰어가 코드리뷰를 하고 approve가 되면
PR(pull request)를 요청한 사람이 직접 merge를 하는데 Squash and merge로 합니다.
Squash and merge를 하는 이유는 나중에 서버를 하게 되면 운영서버에 올리기 전에 특정 기능을 미리 만들어 놓을 수 있는데 이 것을 develop branch에서 관리한다고 가정을 해봅시다.
운영서버에 올리기 전에 필요한 기능(코드)을 cherry pick을 통해서 원하는 PR만 가져와야합니다.
이 것은 개발자가 수동으로 직접 하나하나 commit(pr)단위로 cherry pick을 하게 되는데 이때 squash merge를 하지 않았다면 어디서 부터 어디까지가 해당 기능에 대한 코드인지 구분하기 어렵고 수동으로 옮겨야하는 merge개수도 많아지기 때문에 squash merge를 하고 있습니다.
merge를 하면 작업한 내용이 master(또는 main) 브랜치에 반영됩니다.
merge후 본인의 feature branch는 원격(깃허브)에선 직접 삭제를 합니다.
작업 내용을 코멘트로 정리 후 close를 눌러서 종료합니다.
이 절차의 장점
issue 단위로 작업을 관리해서 나중에 해당 작업 내용을 찾아서 어떤 작업 내용이었는지 이력을 조회할 수 있습니다.
pull request, 코드리뷰를 거치기 때문에 다른 사람이 본다고 생각해서 코드를 더 잘 짜려고 하게 됩니다.
코드리뷰를 하며 서로 몰랐던 부분을 알 수 있습니다
메인브랜치의 보호(master or main)
git checkout main // main 브랜치로 변경
git fetch // 원격레포의 변경 사항 확인
git pull origin main // 원격(main)의 최신 코드를 내 브랜치로 업데이트