github협업

hyerin·2023년 2월 27일

협업을 하려면 github에 organization을 만들어서 시작해야 한다.
팀의 이름을 정하고 팀원을 하나씩 추가한다(처음 시작은 모든 팀원이 권한을 갖는 owner로 시작한다. 이 권한은 다음에 변경할 수 있다.)

협업은 크게 다음과 같은 과정으로 진행된다.

main branch -> clone -> fork -> merge -> pr -> issue

협업 준비

협업을 하기 위해 repository를 만들고 이를 로컬저장소인 .git과 github에 연결해야 한다. (init.remote 명령어 사용)
그다음 처음 시작할 파일들을 main(최종 브랜치)에 push한다. 이렇게 정한 파일들의 구조가 협업의 바탕이 된다.

branch(브랜치)

협업할 때 브랜치를 잘 이해하고 사용해야 하는데, 브랜치란 분기점이라고 생각하면 된다. 최종 브랜치를 main, 세부적인 브랜치를 dev(development branch : 중간 브랜치) 라고 한다.
main 브랜치는 최종 버전의 소스 코드(실 서비스에 배포된 소스 코드)를 관리한다. 그리고, main 브랜치가 아닌 브랜치(dev)를 생성하고 새로운 기능을 개발한 후, 개발이 완료되면, main 브랜치에 병합(Merge)하며 완성한다.

브랜치 관련 명령어

작업할 때 나의 브랜치를 만들어서 작업을 한다. 같은 브랜치를 쓰면 복잡해질 수도 있으므로.. 브랜치 관련 명령어는 다음과 같다

git branch : 브랜치 확인 명령어
git branch 브랜치명 : 해당 브랜치가 내 로컬 환경에 생성된다 (*)
git branch -D 브랜치명 : 해당 브랜치를 삭제
git checkout 브랜치명 : 해당 브랜치로 브랜치 환경을 변경(이동)
git checkout -b 브랜치명 : 해당 브랜치를 생성하고 이동시켜주는 통합 명령어. 다만 해당 브랜치가 그전에 존재하지 않아야 한다.

브랜치 merge(합병)하기

merge란 분기했던 branch(dev)를 다시 원래 브랜치로 합치는 과정이다. branch를 완성한 후 없앨 때 쓴다. merge를 하기 위해서는 main 브랜치에 병합을 해야 한다. 만약 내가 로그인 기능을 개발했고 이 브랜치 이름이 feat/login이라고 하자.

git checkout main(메인브랜치로 이동)
git pull main(메인 브랜치의 정보를 가져오기, 업뎃)
git checkout feat/login (병합할 브랜치로 이동)
git merge main (메인 브랜치에 병합)

위 과정에서 보다시피 메인 브랜치에 병합하기전에 다른 팀원들의 commit사항을 업뎃할 수 있도록 pull하는 과정이 필요하다. 또 중요한건 내가 현재 있는 브랜치의 위치를 잘 파악해서 명령어를 써야 한다.

브랜치 병합이 끝났으면 비어있는 브랜치를 제거해도 된다.
'-d'는 병합된 브랜치를 지울 때 , -D는 병합되지 않은 브랜치를 지울 때 사용한다.

git branch -d 브랜치이름
git branch -D 브랜치이름

merge를 거친다음 push를 한다.

conflict(충돌) 해결하기

merge하는 과정에서 conflict가 생길 수도 있는데, 이를 해결해야 한다.

git status

를 사용하면 현재 상태를 확인할 수 있고, 병합에 실패한 파일을 확인할 수 있다.

충돌지점을 확인하고 수정한 후, 커밋하고 푸시한다.

심화 > 이때, 수정사항이 있어도 브랜치간의 이동이 가능한 명령어가 있는데 바로 stach이다. stach는 스테이징된 파일을 잠깐 저장할 수 있는 코드이다.
원래 수정사항이 있으면 commit후 이동해야 하지만 stach는 이를 가능하게 한다.
수정사항을 잠시 창고에 맡겨 놓고 다시 찾는 개념이다. 그러나 stash를 잘못 사용하다가는 코드가 날라가는 불상사가 생길 수 있다. 코린이 시절에는 사용을 자제해야 겠다.

여기까지 main브랜치에 merge하고 충돌을 해결했다면, 코드가 이상이 없는지 점검하는 test과정이 끝난 것이다. 놀랍게도 아직 main브랜치에 push하는 과정이 남아있다.

중요한 건, 이때 바로 main에 push를 하면 안 된다. 나의 코드를 마지막으로 팀원에게 점검받는 과정이 필요하다.

push전 pull request하기

먼저 원격저장소에 코드점검용 나의 branch를 만들자. 위 사진에서 origin이 원격저장소인데 여기도 main과 test branch로 나누어진 것을 확인할 수 있다. 이는 마지막 main으로 push하기전 거쳐가는 branch라고 생각하면 된다.

git push origin 나의브랜치이름

push를 했다면 pull request버튼을 눌러 pr을 받고, code review를 받아야 한다.

push를 완료하면 본인 계정의 origin repository에 pull request버튼이 활성화된다.

1) branch 설명 옆에 New pull request를 클릭.

2) 메세지 작성후 create pull request누르기

3) 협업중인 원격 저장소에 등록된 pull request는 누구나 merge가 가능하다.
저장소 파일 목록 위의 Pull request를 누르면 등록된 풀리퀘스트 목록이 나옴

4) 풀 리퀘스트 메세지를 살펴본 다음 이상이 없으면 Merge pull request를 눌러 병합한다.

5) 커밋 메시지를 직접 입력하거나 기본메세지를 쓴다. Confirm merge 버튼을 누르면 브랜치 병합 완료된다.

6) 브랜치가 병합되면 해당 브랜치에 있던 파일이 main 화면에 나타난다. 브랜치 상태를 알고 싶다면 파일 목록 위에 있는 '2 branches'를 누르기

7) 브랜치가 병합된 상태라면 'merged'라고 표시됨. 또한 어떤 협업자가 브랜치를 병합했는지도 알수 있음.

8) 깃허브에서 협업을 할 때는 보통 작업자 마다 브랜치를 만들어서 진행하고, 작업 중간중간 풀리퀘스트를 보내서 main 브랜치에 병합합니다. 그래서 깃허브로 협업을 할 때는 다른 작업자의 변경 내용을 바로 반영하기 위해 항상 pull후 push해야 한다.(사소하지만 중요)

원격저장소의 데이터를 복사(clone)하기

이제 다른 팀원이 작성된 코드를 받는법을 알아보자. remote는 한 사람만 하면 되고 다른 사람들은 clone을 통해 코드를 다 다운받을 수 있다.

 git clone 원격저장소url

수정사항을 작성하고 push할 준비를 한다.

이때도 각자의 브랜치를 만들어서 거기에 push한다.

git checkout -b my브랜치이름
이후 수정사항이 있으면 add.commit.push한다

git add .
git commit -m 'feat.message 기능을 추가하였습니다.'
git push origin my브랜치이름

이때도 당연히 바로 main에 push하면 안된다. 자기 브랜치에 PUSH하면 github에서 내 브랜치에 commit이 추가된 것을 확인할 수 있다. 또 옆에 compare & pull request 버튼이 활성화된 것을 볼수 있다.
이때 에러가 없다면 pr를 받고 merge를 진행하면 된다. 이후 필요없는 branch는 없애면 된다.

이 외에도

git fetch

협업할 때는 다른 팀원이 먼저 push했을 수도 있으니 이럴땐 저장소의 최신 버전을 가져와야 한다.패치하면 원격 저장소의 최신 업데이트 버전을 로컬에 가져올 수 있다.

git pull origin main

가져온 변경사항을 현재 브랜치와 merge하려면 pull을 사용한다.
원격 저장소의 변경 내용이 내 로컬 저장소에 반영된다.

git log : 현재 브랜치의 수정 사항을 확인 가능
git log --branch --graph : 브랜치에 관한 사항을 graph형태로 출력
git log -- branch --oneline : 브랜치와 메세지만을 간단하게 확인

git pull origin main --rebase

rebase는 작업한 내용을 반영할 때 커밋을 만들지 않고 반영하는 명령어이다. 작업한 내용을 꺠ㄱ끄하게 유지할 수 있는 장점이 있다. 원격저장소에 있는 변경사항을 먼저 쌓고 그 위에 내가 작업한 변경사항을 쌓는 방식이다. (참고로 커밋은 새로운 버전을 다시 만드는 방식이다.)