협업을 제대로 해본 적이 없어서 협업 방식에 대해서 정리하고자 한다.
코드 리뷰도 제대로 해본 적이 없어서 협업 컨벤션이나 구체적인 루틴에 대한 이해가 필요할 것 같다.
간단하게 정리하고자 한다.
https://backlog.com/git-tutorial/kr/
git 기본 명령어 정리
https://wecandev.tistory.com/152
인덱스(index): 커밋할 변경사항을 모아놓은 궁간임. 작업 폴더(work Tree)의 변경내용을 인덱스에 기록하는 것을 스테이지(Stage)라고 한다.
머지(Merge): 선택한 브랜치에 다른 브랜치에서 커밋한 내용을 병합하는 동작임.
컨플릭트(Conflict):동시에 같은 파일의 유사한 부분을 수정한 경우 발생하는 코드충돌을 의미하고 의도에 맞는 코드를 선택해야 병합할 수 있다.
리베이스(rebase): history를 병합하는 과정.
Pull Request(PR):
깃헙에서 지원하는 기능. 커밋해서 푸시한 변화들을 모아서 해당 변화를 원격 리모트에 반영하는 요청을 보냄. 본인이 보낸 PR을 스스로 머지할 수도 있지만 대체로 리뷰어를 설정해서 해당 리뷰어가 코드를 다시 읽고 이상이 없으면 머지한다.
프로젝트 세팅 시에 쓰는 명령어
git init (현재 프로젝트 폴더를 git 명령어를 통해 접근하게 할 수 있게 하고 로컬저장소로 생성)
git remote (현재 프로젝트에 설정된 원격 저장소를 확인)
git remote add origin "저장소 주소" (해당 프로젝트의 원격 저장소를 추가)
git clone "저장소 주소" (해당 저장소의 프로젝트를 현재 폴더에 복사)
git push origin "브랜치명" (원격 저장소의 해당 브랜치에 코드를 보내는 명령어)
git pull origin "브랜치명" (원격 저장소의 해당 브랜치의 코드를 받아오는 명령어)
git revert (history는 그대로 두고 파일만 이전의 커밋의 상태로 변환)
git merge "브랜치 명" (현재 브랜치에 해당 브랜치에서 커밋한 정보를 병합)
git branch -D "브랜치명" (다 쓴 브랜치 삭제)
git rebase "브랜치명" (현재의 브랜치를 리베이스해서 해당 브랜치와 합치는 명령어, history까지 병합됨)
git fetch (현재 원격 저장소의 상태를 확인)
주의사항
1. 리모트에 반영된 커밋들의 히스토리를 변경하지 마세요
커밋 히스토리를 변경하면 작업 중이던 다른 사람들도 영향을 받는다.
2. 커밋은 자주, push는 필요할 때만 하세요.
일단 push를 해버리면 변경점을 되돌리기가 쉽지 않습니다.
또한 git 저장소에 CI/CD가 설정되어있는 경우 불필요한 자원 낭비가 발생할 수 있습니다.
git 협업 좋은 블로그
https://seungwubaek.github.io/tools/git/contributing_using_pull_request/
form -> clone -> local repo에 원본(upstream) repo 등록 -> branch -> commit & push -> fetch -> solve conflicts -> commit & push -> pull request
헷갈리는 개념 정리
Fork: 다른 사람의 레포지토리를 나의 원격 저장소에 복사
Clone: 레포지토리를 로컬 저장소에 복사
git pull 란?
git pull이란 원격 저장소의 정보를 가져오면서 자동으로 로컬 브랜치에 병합(Merge)까지 수행해주는 명령어이다. 하지만 pull을 이용해서 원격 저장소의 커밋을 가져오게 되면 자동으로 병합되기 때문에 어떤 내용이 병합되면서 바뀌는지 알기 힘들다.
git fetch 란?
패치는 원격 저장소의 커밋들을 로컬 저장소로 가져온다. 그리고 자동으로 병합(Merge)를 해주지 않기 때문에 본인이 직접 확인을 한 후에 병합(Merge)를 하는 과정을 거쳐야 한다.
혼자 작업하면 pull과 fetch를 쓸 일이 거의 없다. 협업을 하다보면 내가 로컬에서 작업할 때 같은 팀원이 원격 저장소에 먼저 변경 사항을 커밋하고 push를 하게 되는 상황이 있다. 그러면 이때 원격 저장소의 업데이트 된 내용이 나의 로컬 저장소에는 최신화가 되어있지 않기 때문에 이럴 때 pull과 fetch를 사용한다.
fetch는 가져온 변경 내용을 로컬에 영향을 미치지 않으며 병합하기 전에 확인하는 용도로 사용한다.
pull은 가져온 변경내용을 로컬에 병합한다. 하지만 로컬에서 작업하다가 변경된 내용을 pull할 경우 충돌이 일어날 수 있다.fetch 후 pull을 로컬이 깨끗한 상태에서 사용하는 게 좋다고 한다.
git rebase란?
말 그대로 base를 재설정한다는 의미이다. 하나의 브랜치가 다른 브랜치에서 파생되서 나온 경우, 다른 브랜치에서 진행된 커밋을 다시 가져와서 base를 재설정하는 것이다. 새로운 커밋을 기반으로 작업을 함으로써 파생된 브랜치는 병합시에 conflict없이 자신의 브랜치에 진행된 커밋을 반영할 수 있다. 그래서 선형 히스토리를 남길 수 있다.
- 장점: 작업 순서대로 커밋 이력이 남는다. 커밋 히스토리가 시간 순서대로 관리되기 때문이다. 또한 불필요한 병합 커밋을 제거할 수 있다.
- 주의점: 파생된 브랜치를 여러 사람이 활발하게 사용하고 커밋이 자주 일어나면 rebase는 위험하다.
git upstream 란?
보통은 다른 레포를 포크해서 내 레포를 만들어 놓고, 내 레포를 클론, 풀 해서 작업한다. 이때 가장 근본의 되는 레포를 upstream이라고 부른다. 내가 fork해서 가져온 레포를 origin이라고 부른다. 그래서 내가 로컬에 클론해놓고 작업할 때 origin/master에서 가져올 지, upstream/master에서 가져와야할 지 생각하고 가져와야한다고 한다.
merge와 rebase의 차이점
https://brunch.co.kr/@anonymdevoo/7
[영상] github에서 브랜치를 만들고 PR 보내는 방법
https://www.youtube.com/watch?v=_giqGNzR1Nc
(branch따기 전에 미리 remote에 있는 코드를 pull로 가져와야 한다.그리고 거기서 브랜치를 다시 따서 작업하면 됨.)
[영상] github 에서 PR을 보내고 다시 PR보낼때 유의 사항
https://www.youtube.com/watch?v=CbLNbCUsh5c
(특정 리포를 포크하고 그걸 로컬에 클론 받고 거기서 브랜치를 만들어서 개발을 하고 PR을 보내고 리뷰를 받고 다시 PR을 보내고 승인을 받으면 머지를 받는 방법을 이전에 봤다. 근데 계속 피쳐를 만들어서 보내는걸 반복할거다. 그러면 문제가 분명 발생할 거다. 왜? merge를 한번 했었으면 반드시 내 로컬의 master를 업데이트를 했어야만 한다. )
어떻게 하면 좋을까?
git remote add upstream <원본 url> (항상 최신으로 싱크를 맞추겠다.)
git fetch upstream (upstream의 내용들을 받아올거다.)
git checkout master (우리가 만든 마스터의 상태를 원본의 마스터랑 맞춰야한다.)
git rebase upstream/master ()
git push -f origin master ()
위 작업을 하면 다시 싱크를 맞출 수 있다.
이상태에서 다시 브랜치를 만들어서 진행하면 이제는 위의 문제가 발생하지 않을 거다.
항상 브랜치 작업전에 로컬이랑 remote랑 싱크를 맞춰놓고 난 다음에 개발해야 한다.
[영상] github에서 conflict 나는 상황
(conflict나는 상황이 뭐가 있을까? 위에서 말한 브랜치 따기 전에 마스터를 맞추지 않는 경우 그리고 처음에 마스터에서 브랜치를 땃을때는 최신이었는데 브랜치를 개발하는 동안 마스터가 업데이트 된 경우! 그리고 PR을 보낼 떄까지는 최신이었는데 PR의 리뷰를 받는 동안에 업데이트를 되는 상황! 즉 마스터가 바뀌는 상황! 이러면 conflict때문에 머지를 못한다. 사실 두 개가 앞에서 마스터를 맞추는 거랑 거의 똑같은 상황이다. 근데 처음 접하면 당황함.! )
나의 브랜치의 헤드를 원본 레포의 헤드랑 맞추면 된다.
git fetch upstream (원본의 상태를 update받는다.)
git checkout master (마스터를 업데이트하자.)
git rebase upstream/master (마스터의 헤드를 이동시킨다.)
git push -f origin master (이제 원본 레포랑 같은 상태가 된다. 포크)
git checkout conflict1
git merge master
git add -A
git commit -m "resolve conflict"
git push
[영상] github에서 fork하여 PR을 보내는 방법
git reset이란?
git reset [commit hash] 사용해서 특정 commit 되돌리기
git reset을 사용하면 대상 커밋 해쉬와 현재 커밋 사이의 모든 커밋(a)들이 제거되고, 해당 커밋들(a)의 변경사항이 보존되는 Plain reset이 일어난다. 이떄 커밋에서의 변경사항은 working directory(unstaged area)에 저장된다.
git reset --hard [commit hash] 사용해서 특정 commit으로 되돌리기
git reset --hard를 사용하면 대상 커밋으로 아예 돌아가버리고 변경사항들이 모두 제거되는 Hard Reset이 수행된다. 즉 현재 커밋과 대상 커밋 사이의 모든 커밋이 제거되는 것은 물론 변경 사항 또한 제거된다.
git reset은 작업 도중 많은 파일들이 변경되었을 때 한번에 되돌리기 위해 사용한다.
git revert란?
git reset을 사용하면 현재 커밋과 대상 커밋 사이의 모든 커밋이 제거되기 때문에 중간의 하나의 커밋만 제거하기 위해서는 git revert를 사용한다.
왜 쓸까?
1~3번 커밋이 있는데 2번 커밋만 제거하기 위해 git reset을 사용하면 3, 2 가 모두 제거된다. 그래서 git revert를 사용한다. 협업에서 중요한데 만약 협업에서 git reset을 사용하면 다른 사람들이 가지고 있는 변경 사항을 내 컴퓨터에서 제거할 수 있게 된다. git revert를 사용하면 커밋의 변경사항을 제거하기 위해 다른 새로운 커밋을 추가하는 것이라서 협업 시에 다른 사람에게 영향을 주지 않는다.
git revert [commit hash] 사용해서 특정 커밋의 변경 사항 제거하기
git revert [commit hash]의 형태로 사용하고 대상 commit hash의 변경 사항이 제거된 파일들이 Staging Area에 올라간다.
reset: 시계를 마치 과거로 돌리는 듯한 행위 (특정 커밋 이후의 커밋이력 모두 없어진다.)
reset에는 3가지 옵션이 있다. hard, soft, mixed
git reset <--option> "돌아가고 싶은 커밋 hash"
hard: 돌어가려는 커밋 이후의 모든 내용을 다 지워버린다.
soft: 돌아가려는 커밋 이력으로 되돌아갔고, 이후의 내용은 stage 상태로 남아있는다. (git add 상태) 즉 커밋을 다시 할 수 있는 상태
mixed: 돌아가려는 커밋 이력으로 되돌아갔고, 이후 내용은 남아있지만 unstage된 상태로 남아있다. (git add 이전 상태, tracked file list)
만약 현재 커밋으로부터 몇개 이전으로 커밋을 되돌리고 싶다면 아래로도 가능하다.
# 현대 커밋 기준 3번째 전 커밋으로 되돌린다.
git reset HEAD~3
revert: 특정 사건을 없었던 일로 만드는 행위
revert는 특정 커밋을 아예 날려버리는 행위이다. 하지만 reset과는 조금 다른 이력이 남음.
내가 특정 커밋을 revert했다라는 이력이 남는다. 이게 reset과의 차이점이다. 또 하나는 reset은 특정 커밋 이후의 이력을 모두 지우지만, revert는 중간에 껴있는 특정 커밋 이력을 날려버릴 수 있다.
언제 revert와 reset을 사용할까요?
reset은 원격 레포지토리로 푸시하기 이전에만 사용한다. 만약 이미 원격 레포에 푸시한 이후에 reset을 하고 push를 하면 에러 메시지를 만난다.
![rejected] error: failed to push some refs to ~~~>git
왜냐면 로컬의 커밋이 원격 커밋보다 뒤에 있기 때문이다. 근데 이걸 git push --force 옵션을 사용해서 push할 수도 있다. 그런데 이미 다른 사람들이 작업한 커밋이 푸시되어있다면 대참사가 난다고 한다.
reset은 혼자만 사용하는 브랜치일때, 다른 사람들이 해당 브랜치를 pull한 적이 없을 때 정도만 사용하는 게 좋다고 한다.
push 이후에는 왠만하면 revert옵션을 쓰는 게 좋다고 한다.
push 이후에 revert를 하면 어떤 커밋에대해 revert를 했는지 커밋 로그가 남아서 좋다. 그리고 다른 사람들이 이후에 작업한 내역도 건드리지 않아서 좋다.
https://coding-start.tistory.com/361
Git 로컬 브랜치를 원격 저장소를 push 하는법
git push 는 로컬 브랜치를 원격 저장소로 푸시한다.
git push <remote> <branch>
사용자가 위 매개변수를 지정하지 않으면 git 은 기본적으로 origin을 원격 저장소로, 현재 작업 하고 있는 브랜치를 푸시할 브랜치로 지정한다.
만약 현재 main.에서 작업 중이라면 git push는 git push origin main이 되는 셈이다.
Git 로컬 브랜치를 다른 이름의 원격 브랜치로 푸시하고 싶다면?
일반적으로는 로컬 브랜치를 같은 이름의 원격 브랜치에 푸시한다. 하지만 만약 그렇게 하지 않는 경우라면?
로컬 브랜치 some-branch를 원격 브랜치인 my-feature로 푸시하고 싶다면 아래과 샅이 작성한다.
git push origin some-branch:my-feature
모든 로컬 브랜치를 원격 저장소로 푸시하고 싶다면?
git push --all
Git remote branch 가져오기 (https://cjh5414.github.io/get-git-remote-branch/)
Git을 사용하다보면 원격 저장소의 branch 를 로컬 저장소로 가져와야할 때가 있다. 협업하고 있는 다른 팀원의 branch를 가져와서 작업을 해야하는 경우가 이에 해당한다.
git remote update (원격 브랜치에 접근하기 위해 git remote를 갱신한다.)
원격 저장소에는 여러 브랜치가 있다.
그런데 원격 저장소의 모든 내용을 pull받고 git branch로 확인하면 기존에 있던 master 브랜치 하나만 있다.
git branch -r (원격 저장소의 branch 리스트를 볼 수 있다.)
git checkout -t origin/feature/create-meeting (원격 저장소의 브랜치를 가져올 수 있다.)
(만약! 굳이 branch 이름을 변경해서 가져오고 싶으면 git checkout -b [생성할 branch 이름] [원격 저장소의 branch이름]) 을 사용하면 된다.
Git flow란?
[필독] https://techblog.woowahan.com/2553/
Gitlab 협업 정리
gitlab이란?
gitlab은 개인 또는 조직이 git repository의 내부 관리를 제공하는데 상용할 수 있는 Github으로 즉 비공개된 Github이다.
왜 gitlab을 쓸까?
gitlab은 중앙 서버에서 Git저장소를 관리하는 좋은 방법
Gitlab은 리포지토리 또는 프로젝트를 완벽하게 제어할 수 있음.
공개 또는 비공개 여부를 무료로 결정할 수 있음.
실무 flow
- gitlab과 github모두 git repository를 중심으로 개발 업무를 진행하는데선 큰 차이 없음
- gitlab은 개발 영영 뿐 아니라 모든 라이프사이클을 커버해서 github보다 많은 편의 제공
- 관리부터 이슈 트래킹까지 포함 모니터링과 보호까지 Gitlab을 써서 한번에 많은 것을 할 수 있음.
- 프로젝트 산출물의 재사용성을 높여서 좋음
- 개발자의 실무에서 가장 큰 영향은 완전한 CI/CI를 통한 DevOps 환경 구축 여부임.
- CI/CD는 애플리케이션 개발 단계를 자동화해서 애플리케이션을 짧은 주기로 고객에게 제공하는 방법
- CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포임.
- CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제인 integration hell을 해결하는 솔루션임.
- CI/CD는 애플리케이션 통합 및 테스트 단계부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공함. 이런 구축을 CI/CD 파이프라인이라 부르고 개발팀과 운영팀의 애자일 방식 협력을 통해 지원됨.
- gitlab은 CI/CD의 많은 부분을 커버하고 컨테이너 레지스트리에서도 좋음.
- 컨테이너 레지스트리는 k8s, 데브옵스 기반 애플리케이션 개발을 위해서 컨테이너 이미지를 저장하는데 사용되는 리포지토리 or 리포지토리 컬렉션임.
- 컨테이너 이미지는 컨테이너의 사본임.
- 그 이미지를 복사해서 빠르게 스케일 아웃하거나 필요에 따라서 다른 시스템으로 이동 가능함.
- 생성된 컨테이너 이미지는 일종의 템플릿이 되고 새로운 애플리케이션을 만들거나 기존 애플리케이션을 확대 및 확장할 때 이 템플릿을 사용할 수 있음.
Gitlab MR Request 정리
PR 및 MR 컨벤션 정리 (https://xo.dev/github-collaboration-guide/)
브랜치를 하나 만들자. 거기서 자유롭게 코딩하자. 작업을 다 끝내고 커밋과 푸쉬까지 끝냈다면 이제 리뷰를 받을 시간이다. Pull Request를 만드는 방법은 여러가지가 있다.
git push --set-upstream origin feat/login 을 하고 푸쉬를 한 뒤 github 프로젝트 저장소에 들어가서 나오는 알림을 따라가도 된다.
아니면 직접 github 프로젝트 저장소의 pull request 탭에서 new pull request 버튼을 눌러도 된다.
합쳐질 브랜치를 확인했으면 create pull request 버튼을 누른다.
이제 내가 한 작업에 대해 적어야 한다. 제목은 간략히 요약해서, 내용은 작업한 내용과 확인받고 싶은 부분을 쓰자.
대충 아래 예시를 비슷하게 적으면 된다.
## 작업 개요
- 회원 가입 페이지 구현
## 상세 내용
기존에 만들어진 Input, Button, Checkbox 컴포넌트를 이용해서 회원 가입 페이지를 구현했습니다.
- 기존 Input 컴포넌트를 Composition 해서 회원 가입 폼에 쓸 컴포넌트를 만들었는데 이렇게 해도 되는걸까요?
- 지금 폼의 상태 관리 로직을 개선할 방법이 있을까요?
우측에서 reviewers를 클릭하고 리뷰를 요청할 사람을 선택한다. 마지막으로 create pull request 버튼을 클릭하면 pull request 가 만들어진다.
내가 리뷰를 해주는 상황?
내가 리뷰 요청을 받았다면 pull request내의 files changed 탭에 들어가서 리뷰를 할 수 있다. 의견을 다 남겼으면 우측 상단의 finish your review버튼을 클릭해서 리뷰를 마친다. 고생했다는 말을 해도 된다.
마지막으로 일반적인 피드백 -> comment
합쳐도 괜찮다 -> Approve
확실하게 코드를 수정하고 넘어가야 하는 경우는 request changes를 선택하고
sumit review 를 누른다.
코드리뷰 반영하기
코드 리뷰를 받으면 pull request 페이지에 리뷰들이 댓글처럼 남겨진다. 여기서 대화를 하거나 개선 방향을 찾고 의견을 수렴해서 코드를 수정해도 된다. 반영된 부분은 resolve conversation을 클릭해서 처리 완료됨을 표시하면 된다.
리뷰를 마치고 코드가 더 수정되었으면 리뷰어에게 다시 리뷰를 요청할 수 있다.
리뷰어가 pull request를 승인하고 병합이 가능하다면 merge pull request 를 누르고 squash, rebase 등의 방식으로 병합한다.
리뷰어로부터 받은 코드리뷰 내용 반영할때마다 리뷰어가 확인하기 쉽게 댓글에 커밋 id 남기기
Commit Convention 정리
https://velog.io/@ye-ji/Git-PR-%EC%9E%98-%EC%93%B0%EB%8A%94-%EB%B0%A9%EB%B2%95
커밋 메시지 예시
Feat: "로그인 기능 구현" -> 제목
새로고침 시 로그인 유지 기능 개발 -> 본문
Resolves: #67 -> 꼬리말
Ref: #64
Related to: #33, #34
제목(subject)
명령어 개조식으로 작성한다.
제목에 대한 표
제목은 과거 시제를 사용해서는 안된다.
제목 첫글자를 대문자로 적는다.
| 제목 태그 이름 | 설명 |
| Feat | 새로운 기능을 추가할 경우 |
| Fix | 버그를 고친 경우 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
| Style | 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서를 수정한 경우 |
| Test | 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경X) |
| Chore | 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경X) |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작엄만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
본문 (body)
커밋의 이유를 설명한다.
어떻게 변경했는지보다 무엇을 왜? 변경했는지를 작성한다.
꼬리말 (footer)
Resolves: #67 -> 꼬리말
Ref: #64
Related to: #33, #34선택사항이다.
issue tracker id를 작성한다면 사용한다.
유형: #이슈 번호 형식으로 작성한다.
유형 예시
| 제목 태그 이름 | 설명 |
| Fixes | 이슈 수정 중 (아직 해결되지 않은 경우) |
| Resolves | 이슈를 해결했을 때 사용 |
| Ref | 참고할 이슈가 있을 때 사용 |
| Related to | 해당 커밋에 관련된 이슈 번호 (아직 해결되지 않은 경우) |
어떻게 커밋 메시지를 잘게 나눌까? (https://jaeheon.kr/257)
커밋의 기본 원칙은 1 Action, 1 Commit 이다.
커밋 메시지만 봐도 이해하기 쉽게 지어야한다.
커밋 단위 쪼개기 요령
- 복잡한 커밋보다는 간단한 커밋을 하자. -> 한 커밋의 한 파일에서 2가지 액션이 들어가는 순간 해당 커밋이 복잡한 커밋이 된다.
- 커밋을 하는 단위는 커밋 메시지 한 줄로 설명할 수 있는 행동이어야 한다.
커밋 가이드
커밋은 반드시 테스트를 통과한 후 해야한다고 한다.
각 커밋은 실 서버에 반영이 되어도 안전한 것이어야 한다. (API 엔트포인트를 하나 개발해서 커밋을 했으면 반드시 커밋을 하고 나서 해당 API와 관련된 인증 검사는 나중에 커밋해서는 안된다. 인증 검사는 애초에 처음 API 커밋할 때 같이 커밋됬어야 한다.)
에러를 트리거하는 코드는 항상 에러 핸들링을 포함한 코드가 같이 포함되어야 한다.
커밋은 최소 단위로
기능 수정과 리팩토링은 동시에 진행하는 것을 피해야한 다.
코드를 원래 있던 파일에서 다른 파일로 옮기는 것은 별도의 커밋으로 진행한다.
2개의 다른 리팩토링을 진행했으면 각각 리팩토링을 따로 커밋한다.
과도하게 세분화된 커밋은 나중에 스쿼시(squash)를 해서 합칠 수 있다. 근데 반대는 불가능이다. 그러니 가능하면 작은 단위로 커밋하자.
브랜치 만들기
브랜치 이름
| 종류 | 사용패턴 | 특징 |
| main | main | 프로덕션 스냅샷, 가장 최신의 배포된 버전 |
| dev | dev | 릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정 |
| feature | feature/이슈번호-이름 or feature/1-branch-name | dev에 병합 |
| hotfix | hotfix/이슈번호 or hotfix/#911 | 메인에 병합 |
브랜치 관련 이미지
Pull Request 작성하기
코드 컨벤션 잘 지키자.
리뷰 가이드 잘 작성하자.
작업중, 리뷰 가능여부를 명시하자. 아직 코드를 작성 중이면 [Wip] (Work in Progress)를 타이틀 앞에 추가하자. 작업이 끝나면 이걸 제거하고 review-needed 태그를 설정한다.
PR 본문 예시
### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트
### 반영 브랜치
ex) feat/login -> dev
### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.
### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.
Github Issue
issue 란 무엇일까?
새롭게 추가될 기능, 개선해야할 기능,. 버그 등등 모든 것이 이슈다.
작업자는 모든 활동 내역에 대해서 이슈를 등록하고 그 이슈를 기반으로 작업을 진행하면 된다.
하나의 기능을 위해 하나의 branch를 생성해서 작업하듯 그 branch의 생성 목적을 issue라고 생각하면 된다.
- 사용자 이메일이 필요한 이슈가 생김
- 그러면 새로운 기능을 만들자.
- 새로운 이슈를 등록하고
- 이슈를 해결할 브랜치를 만들어서 작업하자
milestone이란 무엇일까?
이슈가 하나의 기능을 담당한다면 마일스톤은 작업 방향의 이정표다,
마일 스톤은 프로젝트에서 중요한 이벤트를 표시하는 기준점이고 프로젝트의 진행도를 파악하기 위해서 사용한다.
내 프로젝트가 a -> b -> c -> d의 과정을 거쳐서 만들어진다면 a, b, c, d의 마일스톤을 만들고 각각 마일스톤에 이슈를 붙여가면서 현재 내 프로젝트의 진행을 파악할 수 있다.
한 마일스톤에는 여러 이슈가 등록된다.
[생활코딩] 깃허브 이슈
https://www.youtube.com/watch?v=uc9OKCfb57c
github issue 와 PR
https://minny27.tistory.com/50
https://ebbnflow.tistory.com/260
gitlab 라이프사이클
https://insight.infograb.net/blog/2020/11/18/better-codereview-with-gitlab/
Pull Request는 어느정도 주기 어느정도 단위로 해야할까?
라인(https://engineering.linecorp.com/ko/blog/effective-codereview/)
변화를 작게 유지하자. (300줄 미만)
각각의 PR을 릴리스 가능한 단위 (기능(feature), 버그 수정) 혹은 의미있는 PR이 될 수 있는 하나의 응집된 아이디어로 다뤄야 한다. 너무 많은 수정사항이 포함된 거대한 PR은 좋지 않다.
리뷰는 자주 짧은 세션으로 진행하자.
코드 리뷰는 적절한 양을 정해진 시간 동안 천천히 찾으면서 진행하는게 가장 좋다. 리뷰하면서 코드가 400줄을 넘어가면 리뷰어가 결함을 찾기 힘들다. 1시간에 300줄 정도가 적당하다.
리뷰를 위해 최대한 빨리 PR을 보내자.
커다란 차이점을 뭉텅이로 보내지 말아야한다. 한번에 작은 문제 하나 씩 해결해야 한다
의미있는 PR을 만들기에 충분한 정보를 제공하자.
리뷰어는 제한되어있으니 현명하게 대하자. 리뷰어에게 코드 문맥 이해를 위한 충분한 정보를 제공하자. 왜 어떻게 코드를 변경했는지, 월 완료해서 테스트했고 어떤 부분에 리뷰어가 집중해야하는지 등을 알려주는 것도 좋다. 이런 작업은 Github에서 제공하는 Issue와 PR 템플릿을 사용하면 도움이 된다.
코드 분석 툴을 활용하고 코드 스타일을 확인하자.
ESLint 같은 툴에게 정적 코드 분석, 코딩 스타일 확인 등을 맡기자.
다른 회사의 개발 문화
배달의 민족(https://techblog.woowahan.com/7152/)
뱅크샐러드(https://blog.banksalad.com/tech/banksalad-code-review-culture/)
PR Comment 잘 남기기
리뷰어의 리뷰 시간을 줄일 수 있도록 해줘야 한다. 가장 중요한 것은 '왜'이다.
PR의 제목에서 왜 이 작업을 했는 가를 간단 명료하게 표현한다./
Comment에는 작업에 대한 자세한 (왜?), 작업내용, 미리보기(첨부) 같은걸 작성한다. 미리보기는 이미지, 비디오, 참조 등 을 넣어도 된다.
- 핵심은 리뷰어가 적은 노력으로도 코드 리뷰를 잘할 수 있는 환경을 만드는 것이다.
- PR, MR은 결국 리뷰어를 고려해야 하는 과정의 일환이다.
만약 코드 리뷰를 받고 난 다음 수정 사항을 수정하고 다시 PR을 올리고 싶다면?
1. Review 받은 내용 수정 후 git add
2. git commit --amend 를 통해서 최신 commit 덮어 쓰기
3. git push -f origin {branch-name}
이렇게 하면 이미 올라간 PR에 수정한 부분만 자동으로 반영될 수 있도록 하 수 있다.
즉 다시 PR을 하지 않아도 된다.
코드리뷰 문화
깃허브에서 코드리뷰 하기 (https://joyful-development.tistory.com/14)
코드리뷰는 커뮤니케이션 도구임. 리뷰어, 코드 작성자 서로가 상대방을 배려
주니어도 시니어의 코드리뷰를 함.
코드리뷰에서 승인한다는 것이 모든걸 책임지는게 아니라서 부담갖지 않아도 됨.
읽어보면 좋은 자료 (Good Code Reviews, Better Code Reviews)
https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/
팁
- 현재 해결하고자 하는 이슈나 구현하고자 하는 기능이 뭔지 설명할 수 있는 깃헙 이슈 링크를 걸어놓자.
- 링크를 만들 수 없거나 변경 사항이 너무 사소해서 굳이 이슈를 만들 필요가 없으면 no issue 라고 하자.
- 변경사항은 더 적은 양의 PR로 분리해서 동시에 리뷰를 진행하거나 각각 리뷰할 수 있도록 해주자. 수백라인의 코드 변경사항이 있는 PR을 마주하면 힘들어진다.
- PR의 제목은 간단명료하게 잡자. PR리스트를 봤을때 변경 사항이 무엇인지 빠르게 이해해야한다.
- 코드 읽는 사람들을 위해서 추갖거인 컨텍스트와 왜 변경사항이 필요했는지에 대해 자세한 내용을 남기자.
- 유용한 링크들 (테스트 URL, API 문서 중 관련된 부분에 대한 링크)
- 연관된 PR혹은 비교할 만한 다른 업무
- 스크린샷 (가능하다면)
댓글에 응답하자. 댓글에 응답할 때 어떤 부분을 고려할까?
- 코드와 자신을 동일시하지 말자.
- 왜 리뷰어들이 해당 질문을 했는지 한번 생각해보고 가자.
내가 다른 사람의 코드를 리뷰한다면?
- Acceptance Criteria, Definition of Done 즉 이 작업이 뭘 결과로 내기 위해 한 것인지에 대한 이슈, 티켓이 PR에 링크로 연결되어있는지 확인하자.
- 필요한 정보가 빠져있다면 코드 작성자에게 요구
- 가능하다면 체크아웃을 하고 로컬에서 돌려보자.
- 이해하기 어렵거나 PR에서 생각치 못한 부분이 있으면 설명을 요청하자.
- 멍청한 질문은 없다. 질문하자. (이 기능은 모든 사용자가 접근할 수 있는가? 문서를 추구하거나 업데이트할 계획이 있는가?)
- 대화하자. PR에 댓글을 다는 것이 코드리뷰의 기본 방법이긴 하지만 때론 대화를 하는 것도 좋다. PR에 너무 많은 댓글이 생긴다면 전화를 하자.
- 항상 친절하게 진행하자. 긍적적이면서도 건설적인 억양으로 말하는 것이 좋은 리뷰 환경에 기여한다.
- 높은 수준을 유지하는 것도 중요하지만 새로운 사람들이 코드에 대해 충분히 긍정적인 경험을 할 수 있도록 노력해야 한다.
- 자꾸 같은 부분에 대해 언급하고 있는걸 인지한다면 린팅 룰에 추가하자. 즉 자동화하자.
- 막연하게 그 방법이 좋다는 식으로 평가하지 말고 근거나 대안을 제시해야 한다.
- 누군가를 비난할 수 있는 전문용어를 피해야한다. 코드 스멜이나 안티패턴 등 용어를 조심하자.
코드리뷰를 통해 팀, 회사에서 공통의 코딩 스타일을 유지할 수 있다.
코드리뷰는 지식을 얻기에도 좋다.
구글 코드리뷰 가이드
https://madplay.github.io/post/google-code-review-guide
커밋 컨벤션
https://velog.io/@ye-ji/Git-PR-%EC%9E%98-%EC%93%B0%EB%8A%94-%EB%B0%A9%EB%B2%95
PR request 컨벤션
https://beststar-1.tistory.com/12
https://velog.io/@ye-ji/Git-PR-%EC%9E%98-%EC%93%B0%EB%8A%94-%EB%B0%A9%EB%B2%95
코드 리뷰 숙지 사항
https://xo.dev/github-collaboration-guide/
https://tech.trenbe.com/2022/03/01/CodeReviewGuide.html
git cheet sheat
https://training.github.com/downloads/ko/github-git-cheat-sheet/
git 협업하는 방법 1:
https://12716.tistory.com/entry/Git-GitHub-%ED%98%91%EC%97%85%ED%95%98%EA%B8%B0
git 협업하는 방법 2:
https://deepinsight.tistory.com/78
https://deepinsight.tistory.com/167
gitlab 강의 추천:
[영상] https://www.youtube.com/watch?v=V48d4qJiV4U
[영상] https://www.youtube.com/watch?v=gjNnF85Zt1Y&list=PLmemHGigRiYyP5Ssf0ZkIHvlaZz-BhOYk
git tips
https://github.com/mingrammer/git-tips
추가적으로 아래 링크에서 많은 도움을 받았습니다.
감사합니다.
https://devlog-wjdrbs96.tistory.com/236
https://cross-the-line.tistory.com/m/20
https://dev200ok.blogspot.com/2020/09/git-git-upstream-origin.html
https://developer-alle.tistory.com/315
용어정리
gitlab이란?
https://velog.io/@leyuri/Github-%EA%B3%BC-Gitlab-%EC%9D%98-%EC%B0%A8%EC%9D%B4
코드리뷰
https://tech.trenbe.com/2022/03/01/CodeReviewGuide.html
[영상] 개발자 커뮤니케이션
https://www.youtube.com/watch?v=Pgj0nI68RYM
https://www.youtube.com/watch?v=FFsqIR7KR7s
issue와 minestone이란 무엇일까?
https://jnhro1.github.io/web/2021/06/10/github-issue,milestone.html
이미 올림 Pull Request 수정하기
'인프라 > Git' 카테고리의 다른 글
| [Git] git flow model (0) | 2023.01.01 |
|---|---|
| [Git] Git commit 컨벤션 (0) | 2022.11.08 |
| [Git] git local default branch 변경과 remote default branch 변경 (0) | 2022.10.31 |
| [Git] Hyper-v 설정 적용 이후 Git push 에러 (0) | 2022.09.21 |
| [Github] private repository 에 push하기 + ssh-keygen (0) | 2022.08.18 |