git으로 분산 버전 관리를 통해 협업을 해보자
코드를 수정할 때 결과물이 원하는 대로 안나와서 다시 돌리려는데 저장이 되어 뒤로 못돌리는 경험을 한번씩은 했을 것이다. 이 경우 과거의 코드가 기억이 나지 않아 정말 나쁜 쪽으로 가면 이 부분때문에 프로젝트를 포기하는 경우가 생길수도 있다.
그래서 이 문제에 보완점으로 코드를 버전별로 서버에 올리고 관리하는 분산 버전 관리 시스템이 탄생하였다.
분산 버전 관리 시스템이란?
개발자들이 협업을 할 때 어떤 방식으로 할까?
단순히 코드만 써서 배포하고 끝날까? 아니다.
코드가 들어있는 저장소를 복제하여 로컬에 사본을 만든 후 그것을 수정하여 제출을 한다. 제출한 것은 중앙 관리자를 통해서 병합을 할 지 거절을 할 지 결정되어진다.
이 방법을 쓰지않고 잘돌아가던 코드를 그대로 수정한다면 오류가 났을 때 상상도 할 수 없는 끔찍한 상황이 벌어진다.
(필자도 유지보수의 목적으로 외주를 받은 적이 있는데 고쳤으나 오류가 있던 소스코드를 그대로 배포해서 다음날 다시 불려갔던 적이 있다... 그래도 타임내에 해결은 했다.)
말 그대로 개발자들이 독립적으로 로컬에서 작업하여 새로운 버전을 병합하거나 거절을 하는 것이 분산 버전 관리 시스템이다.
분산 버전 관리 시스템 중 가장 유명한 git의 Git Flow에 대해서 오늘은 살펴보고자 한다.
Git Flow?
Git의 로컬에서 서버로 올라가는 과정
위와 같이 기본적인 순서는 git add, git commit, git push로 이루어진다. 하지만 프로젝트 규모가 커짐과 동시에 협업하는 동료들이 많아지면 하나의 branch로는 감당하기 힘들 것이다.
여러 branch로 나누어서 독립적으로 작업을 하고 특정한 순서를 부여한 것이 Git Flow이다.
Git Flow
조금 복잡한 것으로 보인다. 쉽게 말해 branch별로 나누어 어느 부분에 포함시킨다는 내용이다.
이제는 branch의 종류와 어떤 작업을 하는지에 대해서 알아보자.
Git Flow 구성
Git Flow는 아래와 같이 총 5개로 나뉘어져있다.
-
developbranch -
masterbranch -
featurebranches -
releasebranches -
hotfixbranches
develop, master
어떻게 생각하면 이 두 개의 branch가 가장 최종 지점이라고 볼 수 있다.
-
master는 현재 배포되어져있는 production의 상태와 일치한다.
그래서 보통 작업하다 오류가 엄청 많이 나면 로컬에서 작업하던 것을 모두 삭제하고 master로 다시 클론하곤 한다. -
develop은 현재 배포전 개발이 완료된 상태이다.
언제든 이것을 배포할 수도 있고 이 브랜치에서 더 수정이 들어갈 수도 있다.
feature branches
develop브랜치에서 기능들을 추가 작업을 위해 만들어진 branch가 feature branch 이다.
develop을 현재의 개발 완료 상태와 일치하면서 다른 동료와 conflict가 생기는 것을 방지하기 위해 사용한다.
realese branches
develop브랜치에 이번에 추가될 기능들이 모두 merge가 되었다면 QA(소프트웨어 테스팅)을 위해 realese branch를 생성한다.
이후 QA에서 발생한 버그들은 모두 realese branch에서 수정되어 진다.
hotfix branches
만약 devlop과는 독립적으로 현재 배포되어져 있는 production에서 문제가 생겼다면 hotfix branch를 만들어 여기서 수정되어 진다.
글을 마무리하며
오늘은 분산 버전 관리 시스템과 한 방법인 Git Flow에 대해서 알아보았다.
필자는 그렇게 대형 프로젝트를 아직 경험하지 못하여 Git Flow에 대한 경험이 없었다.
공부를 한 후 느낀 점은 대형 프로젝트의 개발 단계에서는 꼭 필요한 룰이라고 생각이 든다.
한편으로는 CI/CD를 지향하는 개발 상황에는 많은 불필요한 작업들이 많이 나와 Git Flow가 적합하지 않다라는 의견도 있다.
이러한 부정적인 견해를 보았을 때 방법과 툴은 항상 적절한 곳에 쓰여야되는 것이 나의 생각이다.
