#2. Git & Github

프로젝트 버전관리는 git과 github을 사용해서 관리했습니다

 

 

개요

 

git kraken, git desktop 같은 툴을 사용하지 않고

배운대로 git bash 터미널을 사용했었습니다

터미널로 git을 사용해보는게 GUI 툴을 사용하는 것 보다는 더욱 도움이 많이 된다기에 배운 그대로 사용하고 있었죠

 

실제로 2차 팀 프로젝트 당시 저는 인텔리제이의 내장 GUI를 사용해서 git을 사용해봤었는데

명령어로 사용했던 과정을 알고나니까 툴 사용도 쉬웠습니다

 

프로젝트 repository는 제가 먼저 생성하고 url를 공유해 팀원들이 clone 하도록 했습니다

그리고 하나의 repository에 작업해야했기 때문에 Collaborator로 모든 팀원을 등록시켰습니다

 

---

Q. 왜 fork를 하지 않고 Clone - Collaborator 방식으로 진행했나요?

모든 팀원들이 git & github 사용에 익숙하지 않았습니다

저는 fork 기능 자체를 자세히는 몰랐었던 상태였지만 Pull Request와 브랜치 개념을 모르시는 분들도 있었습니다

때문에 여기서 'fork를 해서 복제하고 이후에 작업과정을 PR 한다~' 는 과정을 이해하고 넘어가기엔 어려울 거라고 생각했었습니다

---

 

 

---

 

 

과정

 

검색하면 흔히 나오는 git-flow 전략이 있습니다

지금 검색해도 바로 나오는 우아한 기술블로그에 설명이 잘 되어있는걸 볼 수 있습니다

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

 

그리고 저는 이 버전 관리 모델을 사용하고자 바로 적용시키고자 하였습니다

 

여기서 간략화 해서 'master - feature' 브랜치만 사용하였습니다

feature 브랜치 명칭은 각자 '이니셜/기능'으로 정했습니다

저 같은 경우에는 Naellu라는 닉네임이었기에 'nae/order-01' 과 같이 feature 브랜치를 만들어 작업했었습니다

 

이렇게 작업한 각자의 feature 브랜치를 master에 PR하도록 해서 코드 갱신을 시켰습니다

 

---

Q. 너무 간략화 하신게 아닌가요? master에 바로 push하는 것과 다름이 없어 보이는데요?

맞습니다. 적어도 배포 브랜치와 기능 브랜치 사이에

중간 브랜치 하나 정도는 만들었어야 했다는 생각이 프로젝트 진행 도중, 끝나고 나서야 깨닫게 되었습니다

 

왜 release나 develop같이 다른 브랜치가 없었냐면은

처음엔 프로젝트가 규모도 작고 git을 활용한 협업이 목적이지 git-flow가 목적이 아니기 때문에

'master - develop - feature' 처럼 하려고 했습니다

이렇게만 해도 배포 브랜치인 master에 바로 push하는 불상사는 막을 수 있다는 생각을 했었기 때문입니다

 

하지만 프로젝트 시작 당시 얼마 되지 않아 develop 브랜치의 사용을 중지했습니다

제대로 확립되지 않은 git 브랜치 전략과

심지어 git 관리를 해야하는 저의 git 지식 부족 등등과 같은 복합적인 이유가 많았습니다

때문에 develop브랜치의 사용을 중지시키고 github에서 삭제시킨다음

master만 사용하게 되었죠

---

 

또한 코드의 갱신은 PR을 이용한 merge만 사용하였습니다

PR등록 시 충돌 해결은 각자 알아서 해결한 다음 올리는 방식으로 하였습니다

 

 

 

 

---

 

결과

 

일단 한 마디로 압축해보자면 '어찌저지 굴러는 갔다' 라고 말할 수 있습니다

 

다들 처음이지만 git과 github을 사용하면서

점점 익숙해지신 분들도 있었고 아직 감을 잡지 못한채 방법만 익히시는 분들도 있었기 때문입니다

 

문제점은 당연히 여러가지가 있었습니다

 

모든 팀원을 Collaborator로 등록했기에 모두 관리자 권한을 가지고 있었고

당연히 master에 바로 push할 수 있는 권한도 주어지게 됩니다

 

그래서 한 팀원분이 master에서 기능 브랜치를 생성하는 것을 잊어버린 채 작업을 하신 다음,

PR하기 위해서 자신이 작업한 기능 브랜치를 origin에 등록시키려고 커밋할 때 master에 해버린 경우가 있었습니다

다행히 origin에다가 push를 하신게 아니어서 커밋에 새 브랜치를 붙이고 리셋을 시켜서 master 코드를 돌려놓은적이 몇 번 있었습니다

 

이런 적이 종종 있어서 그런지 하나의 브랜치로만 사용하는게 되게 불안정하다는 느낌을 받았었습니다

바로 push를 해도 문제가 없다면 괜찮지만 문제가 하나라도 있었더라면?

다른 사람의 코드가 없어진 채로 push가 되었던 것이라면?

이라는 걱정이 계속 들었습니다

적어도 백업용이라도 있었다면 돌아갈 구실이라도 남아있는게 아닌가 하는 생각이 들었던 것 같네요

 

 

그리고 프로젝트 종료 이후에 찾아보니 이는 github flow 라는 방식과 매우 유사했었습니다

운영 브랜치를 하나만 남겨 간소화 시키는 대신 그만큼 코드 관리에 철저히 신경쓰는 git 프로세스입니다

 

한 가지 말씀드릴점

과정에서 언급한 git flow의 변형 방식을 사용중이라고 제가 말씀드렸는데

git flow를 변형시켜 사용한 것이 아니라 말 그대로 github flow 방식을 그대로 사용하고 있었습니다

내용을 고치지 않고 그대로 작성한 이유는

현재는 프로젝트 종료 이후에 작성한 게시글이지만
그 때 당시에 저렇게 생각했기 때문에 그 느낌 그대로를 표현하기 위해 작성했습니다

 

확실히 좋은점으로는 github flow의 장점과 동일하게

코드가 항상 최신이라는 것, git flow보다 신경쓸 부분이 적어 관리가 단순한 것 등이 잘 느껴졌습니다

다만 단점은 코드 리뷰와 같은 규칙이 없었기 때문에 버그발견, 코드오류 같은 걸 쉽게 놓쳤으며

팀원간의 피드백 과정이 이루어지지 않아 전체적으로 보기에 코드가 많이 부실했을 수 밖에 없었습니다

 

 

 

 

 

 

 

 

---

 

 

 

팀장으로서의 git 관리는 어떻게 이루어졌을까를 포스팅 해봤는데

거의 일기장 느낌으로 작성되었다고 많이 느끼셨을 것 같습니다

제가 느낀점 위주로 작성하다보니 방향이 이렇게 흘러갔네요

 

다음에는 제가 담당한 구현기능에 대해 포스팅해보겠습니다

감사합니다