4 min read

Git 으로 협업을 해보자

2020-08-15

Git으로 협업을 해보자. 하나의 작업 공간에 여러명이 작업 할때 좋은 협업 시스템으로, 아직 왜 하는지 깊게 파악은 못했다. 그렇지만 많은 회사에서 사용하고 있고 그에 발 맞추어 나도 우리도 같이 사용해야 하기때문에 한번 정리 해보는 시간을 가져 보려 한다. 추가로 Git으로 협업 하는 방법은 여러가지가 있는데, 다음에 Gitflow를 정리 해서 올려보려 한다. 이번에 쓰는 글은 Git을 Fork를 사용해서 협업 하는 방법이다. 이번 글은 하나의 작은 시나리오를 만들어서 진행 하려 한다. 단순히 fork 하는 방법, merge 하는 방법에 대한 코드를 쓰려는게 아니다. 개인적으로 나에게 git은 진입장벽이 높아 어려웠고, 구글을 통해 방법을 찾자니 글과 코드로는 머릿속에서 개념을 이해하기가 어려웠기 때문이다.

Step 1

우선 하나의 깃 레포지토리에서 부터 시작한다. 이곳은 원본이며 버전은 35까지 개발이 되어 있다. 여기서 말하는 버전은 각각의 개발자가 적당히 시간순으로 완성,저장한 개념이라고 보자.

Step 2

일단 A,B는 이 35버전의 깃을 복사한다. 깃에서는 이를 Fork 뜬다고 표현을 한다.

Step 2-1. Git Fork

Git Fork는 다음과 같이 원본 깃 우측 상단(Github 기준)에 Fork 버튼을 클릭하자.(좌) 그리고 내 개인 깃에 가면 원본 깃이 복사된것을 확인 할 수 있다. 이제 이를 가지고 작업을 시작 하면 된다.

Step 3

먼저 A가 버전 35를 36으로 코드를 수정 한다. 그러나 이 36버전은 A의 개인 git에만 적용된것 이므로 이를 원본 Repo에 적용을 해주자.

Step 4

A의 버전 36 깃을 원본 레포에 적용을 해주는 과정이다. 이를 Pull Request라고 표현을 하더라.

Step 4-1. Pull request

Pull request 1

Pull request 하는 방법을 알아보자. 우선 작업해두었던 나의 깃으로 가보자. 그리고 Pull requests 탭에서 New pull request 버튼을 클릭한다.

Pull request 2

그리고 나서 Create pull request 버튼 클릭. 중간에 Comparing changes panel을 확인해보면 나의 깃에서 전달할 깃의 브런치와 정보를 알 수 있다. 이부분에 대한 이해는 일단 넘어가는걸로..

Pull request 3

원본 Repo에 적용을 해주는 마지막 과정이다. 버전 35에서 36으로 바뀌었으니 이에 대한 간략한 정보를 적어주자. Create pull request버튼을 클릭하면 자동으로 적용 되는게 아니다. 이를 확인하고 관리자가 Merge를 해주어야 하는데, 이에 대한 정보가 없을 경우 작업에 큰 혼선을 주기 때문.

Git merge

Pull request를 했으니 원본 레포의 관리자는 어떠한 것이 변경 되었는 지 확인 하고 Merge 해주는 과정을 밟게 된다. 이곳에서는 간단히 View로만 남기도록 하자.

Step 5

이렇게 최종적으로 원본 Repo에도 버전 35 -> 36으로 변경 성공.

Step 6

이제 다음 상황을 보도록 하자. A가 개인적으로 작업해서 36버전을 원본 Repo에 옮겼으나, B는 아직 35버전에 머물러 있다. 그럼 B도 작업을 해서 36버전을 만들면 어떤일이 생기는가?

  • Ver 36-A
  • Ver 36-B

이렇게 두개의 Ver 36이 생기게 된다. 이를 방지 하기 위해 B는 원본 Repo와 동기화를 시켜야 한다. B의 Ver 35를 원본 Repo, A와 동일하게 36 으로 동기화 하는 과정을 보도록 하자.

Step 7

동기화를 이해하기 위해 B의 깃과 원본 깃의 관계를 좀더 자세히 알아볼 필요가 있다.

Step 8

좀더 자세히 파악하기 위해서는 원본 깃, B 깃, 그리고 개인이 작업하고 있는 Local의 공간으로 나뉘어져 있다. 개인의 Local 에서 작업을 하고 B의 깃으로 커밋,푸쉬를 진행 하는데 문제는 개인 Local에 원본 깃이 연결되지 않았다는 점.

Step 9

그럼 개인의 Local 에 원본 깃을 연결 시켜 주자.

깃에서 remote의 개념을 사용하는데 깃 경로에서 다음의 코드를 확인해보자.

$ git remote -v
$ origin  https://github.com/Unfinishedgod/hugo_blog.git (fetch)
$ origin  https://github.com/Unfinishedgod/hugo_blog.git (push)

이제 이곳에 원본 깃을 추가 시켜주자. 코드는 다음과 같다. 위 그림에 원본 Repo와 Local에 upstream으로 연결 하는 코드를 의미한다.

$ git remote add upstream (원본 Git URL)

그리고 나서 다시 git remote -v 코드로 확인을 해보면 다음과 같이 나오게 된다.

$ git remote -v
$ origin  https://github.com/Unfinishedgod/hugo_blog.git (fetch)
$ origin  https://github.com/Unfinishedgod/hugo_blog.git (push)
$ upstream (원본 Git URL)
$ upstream (원본 Git URL)

Step 10

git remote -v 코드를 통해 확인해보니 origin과 upstream두가지가 생성 되었다.

  • origin에는 B가 작업한 ver 35의 코드가,
  • upstream에는 원본의 36버전의 코드가.

이제 Local(origin)에 우선 36버전의 코드를 합쳐주자. 위 그림의 Merge를 해주는 코드를 의미한다.

$ git fetch upstream
$ git checkout master
$ git merge upstream/master

Step 11

Local에 변경된 36의 버전을 B의 git에 적용(push)해주도록 하자.

$ git push origin master

Step 12

이것으로 원본 Repo와 A, B의 모든 버전이 36으로 동기화를 시켜 주었다. 다음 과정은 간단하다. B는 작업을 하고, Pull request를 요청 하고, 원본 Repo의 관리자는 이를 확인하고 버전 37로 진행 해주고.

Step 13

A가 진행 했던 과정을 B가 진행하는걸 간략하게 표시 해두었다. Ver 35로 시작되었던 원본 Repo는 A에 의해 36버전으로, B에 의해 37버전으로. C가 추가 되면 또 위와 같은 방법으로 앞으로 계속 진행 될것이다.

총평

그림이 들어가서, 정말 많은 스크롤이 내려가는 글을 쓰게 되었다. 사실 3~5번 이상 드레그 하는 글을 쓰는걸 별로 좋아 하지 않는다. 글이 길어질때 보통은 블로그를 나눠서 쓰곤 한다. 그러나 이번 글은 잘 나눠서 쓸 자신도 없고, 나눠서 쓸때 흐름이 깨질수 있다고 판단해서 나름 긴 호흡의 글이 되었다. 이와 관련해서 써야 할 글은 다음과 같다.

  • Git시작 하는글
  • Gitflow에 대한 글.

이번 블로그는 git에 대한 기초적인 지식이 있어야 이해를 할수 있기 때문. 사실 git을 시작하는데, 감을 잡지 못해 1년이 넘게 시도/실패를 반복 해왔으니. 아무리 따라 해보려 해도 머릿속에서 그림이 그려지지 않아 따라 할수 없었으나, 꼭 따라해보면서 Git을 시작할 수 있는 글을 작성해봐야 겠다. 그리고 gitflow는 워낙 유명해서. 이 역시 아직 천천히 배워가는 단계라 조금 더 지식이 쌓이면 그때 써보도록 하겠다.