[GitHub] 다른 사람들과 협업하기

Junyoung_Hong·2023년 7월 10일

github

Git

목록 보기

2/2

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. 폴더 생성하기

이메일로 팀장의 초대를 수락하고, 팀장의 repository로 가보자.
터미널에서 작업할 폴더를 만들 곳으로 이동하자. 필자는 보통 데스크탑에 폴더를 생성하기 때문에, 아래의 명령어로 데스크탑으로 이동을 하겠다.
```
cd desktop
```
repository에 올려져 있는 파일들을 다운받을 차례다. 터미널에 아래와 같이 명령어를 입력하자. repository에 있는 파일들을 자신의 로컬에 복사하여 가지고 오는 것이다.
```
git clone https://github.com....
```
- https로 시작하는 부분은 repository의 url이다.

2-2. branch 생성하기

이제 자신의 데스크탑에 폴더가 생성된 것을 볼 수 있다. 다음으로는 branch를 생성해야 한다. branch에 대한 내용은 추후에 포스팅 할 예정이다.

아래의 명령어로 브랜치를 생성하자.
```
git branch 생성할 브랜치 이름
```
- 어떤 브랜치가 생성되어 있는 확인을 하고 싶을 때는, git branch 를 입력하면 된다. 현재 선택되어 있는 브랜치 앞에는 * 표시가 있다.
아래의 명령어 중, 한가지로 자신이 생성한 브랜치로 이동을 하자.
- 예전에는 checkout 을 사용했지만, 요즘에는 switch를 사용한다고 한다.
```
git checkout 이동하고 싶은 브랜치 이름
```
```
git switch 이동하고 싶은 브랜치 이름
```

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 브랜치 이름
```
- 만약 push가 되지 않는다면 아래의 명령어를 이용하자.
```
git push -f 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을 사용할 때는 금방 익숙해지지만, 다른 사람들과 협업을 할 때 사용하고자 하면 난이도가 급상승해진다. 아마 수많은 오류와 충돌을 해결하기 위해 많은 시간을 쏟아야 할 것이다. 그렇지만 언젠간 익숙해지는 날이 올 것이라 생각하면서 열심히 사용해보자.

Junyoung_Hong

iOS 개발자를 향해 성장 중

이전 포스트