[Git] 깃허브로 협업을 해보자(commit, PR, merge, code review 등등)

깃허브는 모두 알다시피 리모트 환경에서 협업을 하기 쉽게 만들어져 있다.

깃으로 협업한다 협업한다 하는데 어떻게 협업하는지,좋은 협업 방식은 무엇일지 포스팅에서 알아보도록 하자.

 

먼저 해당 포스팅을 보고 기본적인 깃허브와 소스 코드를 연결해보도록 하자!
https://parkparkpark.tistory.com/53

[Git] vscode 연동 및 branch 생성, commit / PR(Pull requests) 하는 법

 

1. 내 저장소에 초대하기(or 초대 받기)

깃허브 아이디, 이메일 등으로 초대할 수 있다!

(저장소의 public, private 특징은 상관없이 초대를 모두 할 수 있고, 변경해도 멤버는 유지된다.)

초대를 수락하면 끝!

 

그럼 같은 저장소를 공유하므로 git clone을 통해 원격의 저장소에 push, pull 등 모두 진행할 수 있게 된다.

git clone을 통해 본인의 로컬 저장소에 해당 저장소를 원격 연결해보자! 해당 주소를 복사하고, vscode로 들어가자.

 

F1 을 누르고 git clone을 작성한 후 url을 복사해준다.

클론한 폴더에 들어가보면 잘 적용이 되어있을 것이다. 

협업 방식은 git flow 방식을 사용하면 좋지만, 해당 사안은 나중에 프로젝트 규모가 커졌을 때 고려해보면 좋을 것 같다.

아래는 깃 플로우 관련 포스팅이다.
https://parkparkpark.tistory.com/169 

[Git] Git flow 프로젝트 관리 기법

보통 함께 작업하면 main(or master) 브랜치에서 새로운 브랜치를 따서 작업한다.

이유는 간단하다. 메인이 계속 바뀌면 다른 작업자는 원격과 다른 환경에서 개발을 진행하게 되어 수 많은 충돌을 맞게 될 것 이며
엄청난 비효율을 초래할 것이다!

보통 main 브랜치에서 새로운 브랜치를 따고, 여기서 작업한 후 Pull Request(이하 PR)를 날려 코드리뷰 후 merge한다.

예시를 들어보면

$ git branch edu
$ git checkout edu

$ git branch // 로컬 브랜치 및 현재 브랜치를 알 수 있는 명령어!

main 브랜치를 베이스 브랜치로 edu라는 브랜치를 생성하고, 이동한다.

해당 브랜치에서 기능 작업을 하고(위는 간단한 예시이다.)

$ git add .
$ git commit -m "커밋 메시지"
$ git push origin <새로 생성한 브랜치 이름>  ex) git push origin edu

여기까지 하고 저장소로 다시 돌아와보면

원격 브랜치에 새로 생성한 브랜치가 잘 올라간 걸 확인할 수 있으며, edu로 들어가보면 커밋이 생기고 PR을 날릴건지 물어보는 바가 생긴 걸 알 수 있다.

Compare & pull request를 누르고!

 

위에 base에 원하는 브랜치가 넣어져 있는지 확인한 후

오른쪽에 팀원을 리뷰어로 선정하고, 정성스럽게 PR을 작성하고,
Create pull request를 눌러보자!

그럼 해당 화면을 만날 수 있다. kenny의 review를 기다려보자..!

(아래부터는 팀원인 kenny 시점입니다)

kenny가 Files changed로 가서 리뷰를 해주고 

모든 리뷰를 끝냈다면 우측 상단에 Finish your review를 누르고 Approve를 누르고 Submit review를 누르면 리뷰 완료다!

다시 제 시점으로 오면

kenny가 제 코드에 대한 문제점 및 야기할 수 있는 문제점, 사이드 이펙트 등을 판별하고 리뷰를 해주고, (칭찬도 해줘야함!)

Reviewers의 리뷰가 끝나면(Approve가 되면) 오른쪽 상단처럼 체크표시가 나오는 걸 확인할 수 있다.
저게 나올때까지 팀원에게 코드리뷰 해달라고 징징거리면 된다.

만약 큰 문제점이 없고, 개선사항이 없다면 merge를 해보도록 하자!

(merge는 모든 팀원들이 할 수 있지만, 보통 본인이 책임진다는 마인드로 PR을 올린 본인이 Merge한다.)

누르고 누르면

main 브랜치에 제 작업이 정상적으로 올라간 걸 확인할 수 있다.
이러면 보통 작업하는 다른 사람들이 다시 main 브랜치 pull을 받아야한다. (사이드 이펙트 및 충돌 방지!)

kenny가 작업중이었다면 

$ git pull origin main

을 작성하고 원격의 main 브랜치를 pull 받아야한다. (연관된 파일이 있으면 더더욱)
(그러나 프로젝트 규모가 크고 작업이 크게 겹칠 일이 없다면 매번 받을 필요는 없습니다.)

위 방법을 따르지 않고 터미널에서 바로 브랜치를 merge를 하는 방법도 있지만
이건 협업에서 상당히 좋지 않은 방식이다.

변경된 파일을 감지하기도 어렵고, 리뷰는 당연히 안되며, 정말 많은 문제점이 생긴다.. (금지)

 

협업에서는 브랜치 생성 => 작업 => PR => 코드 리뷰 => merge 방식을 추구하면 좋다!

 

아마 현재 감이 안 잡힐수도 있지만, 계속 해보시다보면 잘 잡힐 것이다! 

그리고 이미 작업한 브랜치는 이제 쓸데 없으므로 로컬, 원격에서 삭제해도 무방하다

 

다들 협업으로 멋진 프로젝트를 개발해보자 :)