Github 협업 - branch 연습하기

12월 28, 30일에 실행한 git 협업 연습에서는 기초적인 시나리오만 진행했다. 한참 뒤에 쓰는 거라 매 단계를 상세히 작성하기 어려워 뼈대만 남긴다. 이 글에서는 28일 내용을 기록했다.

1. branch를 나누지 않았을 때 어떤 문제가 생기는지 체험

2. branch 나누고 반영하기

3. conflict 해결 연습

준비

* git 강의 하나 정도는 들은 머리 : 에러 메세지 이해를 못하면 곤란하다.

* 같이 할 사람 2명 이상 : 세명 이상이면 두명일 때보다 더 많이 연습할 수 있다.

* 버려도 되는 github repository(이하 repo) : 날려먹는 건 아니지만 연습장이 필요하다.

* 에러가 나도 포기하지 않고 변경 사항을 밀어붙일 마음가짐 : 해결할 수 있으니 타협 금지.

한 개의 repo를 사용하여 contributor로서 협업하기

1. repo에 txt 파일 여러개를 넣어둔다.

 

2. repo 주인이 다른 사람들에게 contributor 초대를 보내고 각자 수락한다.

repo 들어가서 맨 우측 탭, settings > Manage access에서 할 수 있다. 초대를 받은 사람들은 메일이나 github 알림을 확인하여 꼭 수락해야 된다. 늦게 확인하면 초대가 만료되어 있을 수도.

 

3. repo 주인 외 다른 사람들은 각자의 로컬에 repo를 clone한다.

repo에 있는 초록색 code 버튼을 누르면 clone > HTTPS 링크를 볼 수 있다. 이걸 복사한 뒤 원하는 위치에 git bash를 열고

$ git clone 복사한주소

이렇게 치면 해당 위치에 repo 이름으로 폴더가 생긴다. 그 안에 repo의 파일이 들어있다. 이는 repo을 만들고 로컬에서 $ git init과 remote 등록을 해둔 상태와 같다. 이제 사용하고 있던 git bash 터미널에서 repo 폴더로 들어간다.

$ cd 폴더명

 

4-1. 각자 수정한 뒤 로컬에서 main으로 바로 push (비권장)

commit한 뒤

$ git push

또는

$ git push origin main

이 때 다른 사람이 먼저 push를 했다면 에러가 난다. 에러 메세지를 읽어보면 pull을 해서 remote의 현재 상태를 반영하라고 알려준다.

$ git pull

conflict가 난 파일을 열어보면 ===로 줄이 그어진 부분을 볼 수 있다. HEAD와 다른 commit#의 코드가 각각 나와있으니 보고 원하는 것만 남기면 된다. === 등 남길 코드 외의 것들은 가능한 깔끔히 지운다.

이후 다시 push했는데도 같은 에러가 났다면 수정을 미흡하게 하지 않았는지, 또는 그새 다른 사람이 repo에 반영한 게 있진 않은지 확인한다.

위의 내용을 여럿이 동시에 실행하면 연쇄 conflict 지옥을 체험할 수 있다. 그나마 코드랄 게 없는 txt 파일이니 쉽다.

 

이 방법을 비권장하는 이유: main으로 push하면 실행하자마자 반영된다. 코드에 오류가 있다면 main에도 문제가 생긴다. 여러 사람이 각각 수정하는 기능과 commit 빈도가 다른 데, 모두가 수정 사항을 main에 push한다면 다른 사람의 넣어둔 불완전한 코드까지 pull해서 conflict 해결을 해야만 내 수정 사항을 repo에 보낼 수 있다. 매우 불편하고 프로젝트 tree 모니터링도 힘들다.

 

4-2. 각자 로컬에서 branch를 만들고 수정한 뒤 repo의 branch로 push (권장)

로컬에서 branch를 생성한다. branch 명령어 참고 링크

이 때 branch들을 넘나들 때 주의할 게 있었는데 까먹었다. branch를 넘나들 때 commit 안 한 수정 사항은 날아간다는 것만 기억한다.

현재 위치가 해당 branch인지 확인하고 수정 사항을 만든 뒤 commit까지 한다.

repo의 main이 아닌 다른 branch에 push할 때는

$ git push origin branch명

github에서 새 branch가 생겼고 로컬에서 push한 게 들어가 있는 걸 확인할 수 있다. 이제 이 branch에서 이어서 수정하고 반영하면 repo 혼자 쓸 때처럼 살 수 있다. 작업을 여러 branch로 나누어 할 수도 있다(참고 링크).

이 branch를 다른 branch에 합치려면 github의 pull requests 탭에서 새로운 pull request를 만들고 확인을 거친 뒤 merge하면 된다. 이렇게 쓰던 branch가 마무리 되고 main에 합칠 때만 conflict를 고민하면 된다.

이 방법을 권장하는 이유: 수정 사항에 문제가 있어도 다른 사람들이 그 외의 branch를 사용하는 데 지장이 없다. 수정하는 파트, 기능별로 branch를 만들면 모니터링하기 좋다. 무엇보다 내가 push할 때 편하다! conflict 지옥 빈도를 줄일 수 있다!

 

다음 글감은 30일에 진행한 fork를 이용한 협업 연습이다. 미뤄둔 걸 한 번에 쓰기 힘들어 쪼갰다.