깃을 이용한 협업 모델 feat:Git Flow

개발자들이 가장 두렵지만 기쁜(일을 하지 않아도 되어서) 무엇인가 라고 뽑는다면 단연코 내 기준으로 바로 깃 허브가 뻗었을 때 만큼은 정말 두렵다고 느낀다. 그만큼 요즘 시대의 개발자들이 깃을 애용하고 또 깃 허브를 수 많은 개발자들이 이용하고 있다.

출처: https://twitter.com/painter_of_100/media

그렇다면 한가지 의문점이 바로 생길 수 있다. 왜? 깃 이랑 깃 허브가 요즘 개발자들에게 인기가 있는 건가?? 그 이유는 아래의 다음과 같다.

깃이 왜 유명한데?

크게 8가지의 이유가 있는데1 그 중에서도 눈에 띄는 장점을 몇가지 알아보았다.

1. 빠름, 그것도 엄청.

깃을 사용하는 이유는 간단하다 단순한 코드 구성으로 파일의 어떤 부분이 변화 했는지를 중심으로 추적하고 깃의 용량 자체도 적고 다른 인터프리터 언어를 기반으로 둔 것이 아닌 로우레벨인 C를 기반으로 작성이 되었기 때문에 최적화가 미친 듯이 좋기 때문이다.2

다른 버젼 관리 시스템과의 속도 비교.

2. 오프라인으로도 작업이 가능함

버젼 관리 시스템이면서 인터넷이 작동이 되지 않아도 코드를 작성하고 수정을 할 수도 있다!! 오프라인으로 작성을 하고 커밋을 하고 인터넷이 접속이 가능할 때에 리모트에 올리기만 하면 되는 방식으로 작업을 할 수도 있다.

3. 실수를 되돌리기가 매우 쉽다

사람이라면 당연히 한번씩 실수를 하는 타이밍이 오게 되는데 내가 실수를 저질러 버려도 웬만한 상황이 아니라면 실수를 아주 쉽게 커맨드 단 하나로 되돌리수도 있다.
게다가 뒤에서도 언급 할테지만 Git flow 방식으로 협업을 하게 된다면 사용자에게 라이브로 올리는 소스파일을 건들지 않고 수많은 안정화 과정과 또 실험적인 개발을 통한 기능 개선등등 자유롭고 적극적으로 소스를 수정하고 뒤엎을 수도 있고, 실수 혹은 어른들의 사정 으로 원하지 않게 되었던 개발 버젼을 다시 되돌릴수도 있으니 이 얼마나 좋은 것인가.

4. 섞이지 않게 둘수 있다(문자 그대로)

이는 단번에 이해가 되지 않을 수도 있다. 만약 나와 팀원들이 동시에 A라는 파일을 수정했다고 가정해보자. 만약 A라는 파일을 동시에 수정하게 된다면 중복되는 부분이 생기기 마련이다. 그렇게 된다면 같은 줄에서 중복으로 되는 부분이 생길수도 있다. 이 부분에서 합치려고 들었을때 바로 깃의 진가가 나타난다. 바로 Merge Conflict3 라는 오류를 뱉어낸다. 이 오류를 통해서 어떤 부분이 겹치게 되었으니 올바르게 수정해서 다시 작동하게 만들어라. 라는 지시를 받을 수 있다!

위와 같은 이유로 대부분의 개발자들이 깃과 사랑에 빠졌고 애용하게 되었다. 그렇다면 이 글의 주된 내용인 깃을 이용한 다른 개발자들과 협업을 하는 과정이 무엇이며 또 어떻게 하는 것이 좋을 까에 대해서 적어보려고 한다.

깃을 이용한 협업 모델

깃을 이용해서 하는 협업 모델들은 크게 3가지가 있다. 그 중에서도 많은 개발자들이 애용하는 Git Flow 방식에 대해서 알아보자.

Git Flow 협업 모델

깃 플로우를 표현한 간단한 다이어그램
출처: https://www.campingcoder.com/2018/04/how-to-use-git-flow/

깃 플로우에 대해서 설명하기 전 브랜치라는 개념을 알고 넘어가야 한다.

브랜치

브랜치는 단순하게 말하면 개발자의 멀티버스라고 생각하면 편하다. 즉 브랜치를 칠 때마다 현재를 기점으로 아예 새로운 공간을 만들어낸다. 이 브랜치를 통해서 우리가 안정화 되어서 유저가 직접 보는 페이지를 구성하는 소스코드를 보관하는 브랜치 개발을 진행중인 버젼을 관리하는 브랜치 기능을 개발중인 브랜치 그리고 개발을 완료 하고 나서 배포전 안정화 테스트를 하는 브랜치 등등으로 사소한 기능단위로 브랜치를 구성한다. 그렇게 되면 안전하게 소스코드를 보관하면서도 실험적으로 개발을 이어나갈 수 있게 도와준다.

Git Flow 협업 모델? 그건 어떻게 하는데?

깃 플로우 모델을 이해 하는데 있어서 아주아주 적합한 예시가 있다.
바로 온라인 게임이다. 온라인 게임이라면 매주 혹은 적절한 주기마다 패치를 진행 하게 된다.

위의 사진은 예시로 든 로스트아크 라는 게임의 패치 내역중 하나이다.

그렇다면 로스트아크 라는 게임을 예시로 들어보자. 로스트아크는 매주 수요일 마다 점검을 하여 사용자에게 최적화, 품질개선, 컨텐츠 업데이트, 다양한 이벤트를 매 주기마다 업데이트를 진행한다.
그렇다면 Git Flow랑 이게 무슨 관련이 있는 지를 알아보자.

깃 플로우는 흔히 Master 브랜치, Release 브랜치, Develop 브랜치, Feature 브랜치로 구분하여 개발을 진행한다.

• Master 브랜치는 앞서 언급했던 실시간으로 유저가 플레이 하는 게임 버젼의 소스코드를 의미한다.

• Feature 브랜치는 사소한 기능 하나하나들을 의미 한다. 예를 들어서 아바타의 업데이트 최적화 관련 패치 컨텐츠 업데이트 등등을 개발자들이 개발을 하고 이 것이 다음 업데이트에 올라갈만한 정도로 개발이 완료가 된다면 Develop 브랜치로 넘어간다.

• Develop 브랜치는 일반 유저들이 볼 수 없는 공간이다. 이 브랜치에서는 현재 개발중인 feature 브랜치를 합쳐놓아서 Release 브랜치로 넘어갈 준비를 하며 테스트를 거치는 구간이다.

• Release 브랜치는 패치를 하기 전 Develop 브랜치에서 지금 업데이트로 이루저야할 소스 코드 등을 합치고 나서 실제로 테스트를 해서 유저가 큰 문제가 없는지 내부적으로 테스트를 해보고 나서 매주 수요일마다 Master 브랜치로 병합을 해 유저에게 적용된다.

• Hotfix 브랜치는 게임의 핫 픽스를 의미 한다. 예를 들어서 치명적인 오류가 발생해 게임을 실행 할 수 없거나 게임의 컨텐츠의 진행 자체를 불가능하게 된다면 바로 Hotfix브랜치를 이용해서 다른 과정을 거치지 않고 바로 고치는 그 즉시 유저에게 적용되게 된다.

Git Flow 사용방법

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html
위의 링크를 들어가서 다운 받을 수 있다.

Git Flow를 사용하는 방법은 아주 쉽다. 홈페이지에서도 바로 이해 할 수 있게 한국어로 설명이 되어 있지만, 이곳에서도 별도로 서술 하겠다.

1. 먼저 깃 플로우를 등록 하기 위해서 $ git flow init 을 명령어로 입력한다.
2. 여러가지 기초 설정을 해주는 칸이 나오지만 기본으로도 이미 작성된 내용이 있기 때문에 내가 원하는 설정하고 싶다면 설정을 해주고 그렇지 않다면 무지성 엔트를 눌러 설정을 마무리 한다.
3. 기능 개발을 하기 위해서는 $ git flow feature start {featureName} 명령어를 입력해 바로 개발 브랜치로 이동한다.
4. 기능 개발을 완료 했다면 $ git flow feature finishi {featureName} 명령어를 입력해 개발을 완료한다.
5. 모든 개발이 완료되어 배포를 준비 하고 있다면 $ git flow release start RELEASE 입력해 릴리즈 브랜치를 생성해서 배포를 준비하며 버그를 잡고 안정성 테스트를 진행한다.
6. 이제 배포를 하기에 충분하다고 판단되면 $ git flow release finish RELEASE 입력해 배포를 진행한다.
7. 그렇다면 여러가지 커밋 메세지 그리고 tag를 작성하게 되는데 $ git push --tags 이 명령어를 통해 원격 저장소에 푸시 하기 전에 tags를 같이 올려주자.

끝이다. 정말 끝이다. 정말 간단하게 몇줄의 명령어도 아주 쉽게 Git FLow 협업 모델을 사용하게 되었다.
정말 쉬웠다. Git Flow model 적용 시켜야겠네~ Git Flow 애용해야겠는 걸~~

마치며..

이렇게 Git Flow를 이용해 아주 간단하게 협업을 하는 과정을 알아 보았다. 이렇게 쉽고 간단한 명령어를 통해서 사용자에게는 안전한 코드 배포를 또 개발자에게는 실험적으로 기능개발을 편히 할 수 있는 이 Git Flow 모델을 지금 당장 다음 프로젝트 부터 적용시켜 보는 건 어떨까?

Git Flow model 사용 해야겠지???

---

1: https://dev.to/gittower/8-reasons-why-git-is-so-popular-3mj4
2: https://ericsink.com/entries/why_is_git_fast.html
3: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line