0. 여는 글
github에 대해서 글을 작성했었지만, 처음과 혼자 사용할 때 위주로 글을 작성했었다. 이번에는 github의 주 목적인 협업을 할 때, 어떻게 사용해야 하는지에 대해서 작성하고자 한다.
1. 팀장일 경우
우선 자신이 팀장일 경우를 생각해보자.
- 자신과 팀원들이 작업을 할 repository를 만들어야 한다. 이 부분을 잘 모르겠다면 필자의 이전 포스팅을 참고하는 것이 도움이 될 것이다.
- 이제 팀원들을 초대해 보자.
- 자신이 만든 repository의 상단에서 setting을 찾자.
- 그 다음 왼쪽 메뉴들 중, Access에 있는 Collaborators를 누르자. 비밀번호를 입력하라는 창이 뜰 수도 있고, 뜨지 않을 수도 있다. 만약 뜬다면 비밀번호를 입력하면 된다.
- 아래와 같은 화면을 볼 수 있는데, Add people 버튼을 누르자.
- 팀원들의 이메일이나, github 아이디를 입력하자. 그러면 팀원들의 이메일로 초대메일이 간다. 수락을 한 후, 팀원이 팀장의 repository에 들어가면 push를 할 수 있다는 안내를 볼 수 있다.
- 프로젝트의 기본이 되는 폴더나 파일을 repository에 올리자.
- 보통 first commit 이나 initial commit 이라고 커밋 메시지를 적는다.
- 처음 repository를 만들면 빈 저장소이기 때문에, 팀원들이 복사를 할 수 없다.
- 이제 아래의 2-2.의 내용으로 가서 작업을 진행하면 무리가 없을 것이다.
2. 팀원일 경우
이제 자신이 팀원일 경우이다.
2-1. 폴더 생성하기
2-2. branch 생성하기
이제 자신의 데스크탑에 폴더가 생성된 것을 볼 수 있다. 다음으로는 branch를 생성해야 한다. branch에 대한 내용은 추후에 포스팅 할 예정이다.
- 아래의 명령어로 브랜치를 생성하자.
git branch 생성할 브랜치 이름
- 어떤 브랜치가 생성되어 있는 확인을 하고 싶을 때는,
git branch
를 입력하면 된다. 현재 선택되어 있는 브랜치 앞에는 * 표시가 있다.
- 아래의 명령어 중, 한가지로 자신이 생성한 브랜치로 이동을 하자.
2-3-1. PR & Merge (rebase X)
- 자신이 새로 작성한 코드를 커밋한 후, 브랜치로 push를 하자.
git push origin 브랜치 이름
- 이제 복사했던 repository로 돌아가서 pull request를 하자.
- 위쪽에 보이는 버튼을 클릭하자.
- pr을 날린다 라는 말을 들어보았을텐데, 여기서 말하는 pr이 pull request이다.
- pull request를 만드는 화면을 볼 수 있다. Wirte에 간단한 메모(?)를 적은 다음 Create pull request를 클릭하면 pull request가 생성된다.
- conflict(충돌)가 있는지 확인을 한 다음, 없으면 merge 버튼이 활성화 된다.
- 활성화된 merge 버튼을 누르면, main에 나의 브랜치에서 작성한 코드가 정상적으로 합쳐진다.
2-3-2. PR & Merge (rebase O)
- 자신이 작성한 커밋들을 바로 push 하기 전에, main의 히스토리를 깔끔하게 유지하기 위하여 rebase를 해보자.
git rebase main
- -i 를 입력하면, 좀 더 interactive하게 rebase 할 수 있다.
// 내가 작성한 모든 커밋들을 볼 수 있음
git rebase -i main
// HEAD는 가장 최신의 커밋을 뜻함
// 만약 자신이 작성한 커밋이 8개라면
// 끝(가장 최신 커밋)에서 5개의 커밋을 볼 수 있다(4, 5, 6, 7, 8번째 커밋)
git rebase -i HEAD~5
- 이제 글자가 많이 적힌 vim 파일을 볼 수 있다.( -i 가 vim 파일을 연다는 뜻이다.)
- 위에 pick 으로 시작하는 커밋 내용들이 있다. 그 중, 남기고 싶은 커밋만 pick 으로 남기고, 나머지는 pick을 s로 바꾸자.
- s는 squash 의 단축어로, 커밋들을 뭉개서 정리하는 기능을 한다.
- pick을 drop으로 바꾸면 커밋이 삭제가 된다.
- 만약 또다른 vim 파일이 나온다면, 내가 남기고 싶든 커밋만 남기고, dd를 눌러서 모두 삭제해주면 된다.
- 잘 모르겠을 때는 이분들의 글을 참고하자.
- 이제 브랜치로 push를 하자.
git push origin 브랜치 이름
- 이제 복사했던 repository로 돌아가서 pull request를 하자.
- 위쪽에 보이는 버튼을 클릭하자.
- pr을 날린다 라는 말을 들어보았을텐데, 여기서 말하는 pr이 pull request이다.
- pull request를 만드는 화면을 볼 수 있다. Wirte에 간단한 메모(?)를 적은 다음 Create pull request를 클릭하면 pull request가 생성된다.
- conflict(충돌)가 있는지 확인을 한 다음, 없으면 merge 버튼이 활성화 된다.
- Merge pull request라고 적힌 버튼을 Rebase and Merge로 바꾸자.
- Rebase and Merge 버튼을 클릭하면 끝이다.
2-4. pull 땡겨오기
- 다른 팀원들은 아래의 명령어를 이용해 새롭게 바뀐 main 브랜치의 코드를 main 브랜치로 바꾼 다음에 pull 해야 한다.
git pull origin main
- pull을 할 때, 오류와 함께 아래와 같은 힌트를 볼 수도 있다.
- pull 한 파일과 현재 로컬에 있는 파일을 비교했을 때, 충돌이 일어나는 부분이 있어서 생기는 오류다.
- 보통 맨 위의 명령어인
git config pull.rebase false
를 이용한다.
- pull을 하였을 때, 로컬과 hub의 차이가 있을 경우, 비교하여 merge하라는 환경설정을 한다는 의미이다.
git config pull.rebase true
와 기능적으로 똑같지만, 차이점은 rebase false
를 하게 되면 history에 merge 커밋이 붙어서 기록이 된다.
- 좀 더 자세한 내용은 이 분의 글을 참고하면 좋을 것 같다.
- 명령어를 입력하고, 다시
git pull origin main
을 하면 github에서 pull 땡겨온 파일과, 나의 파일의 어디 부분이 다른지 보여준다.
- 이제 conflict가 뜨는 부분을 모두 해결하고, merge를 하면 정상적으로 merge가 된다.
3. 마무리 글
- 크게 보면
git pull
→ git add
→ git commit
→ git push
→ pr&merge
의 반복이지 않을까 라고 생각한다.
- 혼자 git을 사용할 때는 금방 익숙해지지만, 다른 사람들과 협업을 할 때 사용하고자 하면 난이도가 급상승해진다. 아마 수많은 오류와 충돌을 해결하기 위해 많은 시간을 쏟아야 할 것이다. 그렇지만 언젠간 익숙해지는 날이 올 것이라 생각하면서 열심히 사용해보자.