여러분들은 정보 공유에 어려움을 겪은 적이 있으신가요? 당장 저만해도 그냥 제 맘대로 일들을 마구 하는 경우가 많습니다..
하지만 팀 프로젝트를 하거나 미래에 팀 단위로 개발을 하게 된다면 내가 어떤 부분을 어디까지 했는지 다른 사람들도 파악할 수 있어야 원활한 진행을 할 수 있겠죠? 이런 상황에서 도움을 줄 수 있는 것이 바로 버전 관리 시스템입니다.
버전 관리 시스템
개념
저는 학교 수업 중 OSSW(오픈소스SW)기초 수업에서 이와 관한 내용을 들은 기억이 있는데요, 그때 이와 관련된 파트를 배운 적이 있습니다!
버전 관리 시스템은 파일의 변화를 기록해 두는 시스템인데요, 흔히 우리가 PPT 같은 파일을 만들 땐
PPT
PPT(1)
PPT(최종)
PPT(최최최종)
...
이런 식으로 수정 사항들을 각자 별개의 파일로 만들면서 저장을 하는 경우가 많은데, 이런 식의 저장 방식을 파일 저장 시스템이라고 합니다. 이때 문제점은 중복된 부분들을 별개의 파일로 만들어 저장소의 낭비가 생기고, 파일의 수정사항들을 일일히 들어가서 직접 비교해야만 구별 가능하다는 점 등이 있게 됩니다.
이런 문제를 해결하기 위한 시스템이 바로 버전 관리 시스템!
버전 관리 시스템은 파일의 변화(수정사항)만들 별도의 파일에 기록하며 저장된 구분점마다 파일의 수정내용, 추가되거나 삭제된 파일 등을 기록하게 됩니다.
특징
이렇게 별도의 파일이 아닌 수정사항들을 기록하게 된다면..
- 파일이나 프로젝트를 이전 상태로 되돌릴 수 있으며
- 시간에 따른 수정 내용을 비교할 수 있고
- 어떤 부분에서 누가 문제를 야기했는지 역추적을 할 수 있다!
이와 같은 편의성을 얻을 수 있지만 가장 큰 문제 중 하나는... 공부해야한다!
우리가 사용하는 파일 시스템과 비슷하면서도 다른 원리로 동작하고 저장 방식도 직접 지정하고 저장시 내용과 제목등을 효율적으로 지정해 관리의 편의성을 보장하기 위해선 이를 사용하는 방법을 알아야 한다는 점..!
하지만 공부 하기 전에 왜 써야 하는지를 알아야겠죠?
발전 과정
먼저 버전 관리 시스템이 여러 과정을 거치며 발전을 했는데..
→ 간단하게 말하면 로컬 영역에서 버전 관리를 하던 것을 중앙 집중식 서버를 사용하다 분산 버전 관리 시스템으로 발전하였습니다.
각 과정을 아래와 같이 나타낼 수 있습니다.
로컬 영역 -> 결국 한대의 컴퓨터에서만 관리되기에 사람들과 공유에 어려움이 있다
중앙 집중식 서버 -> 서버가 다운되면 모든 업무가 중단된다
분산 버전 관리 시스템 -> 데이터를 여러군데에 저장하고 이를 주기적으로 병합하는 방식으로 데이터 유지
이 중 가장 최근에 발전한 분산 관리 시스템의 대표라고 할 수 있는 시스템이 바로 Git이다.
Git
개념
분산 관리 시스템인 만큼 각자의 컴퓨터, 즉 로컬환경에서 개발을 진행하면서 공통된 원격저장소에 수정사항들을 업로드, 다운로드를 하며 개발을 진행할 수 있습니다. 이때 개발을 진행하는 방향 등 다양한 목적에 따라 여러개의 길을 만들 수 있는 branch를 통해 하나의 프로젝트 안에서 다양한 경로를 만들 수 있습니다.
특징
- 분산형 버전 관리 시스템으로서 각자의 로컬시스템에서 복제본을 저장 가능하다.
- 중앙 집중식이 아니기 때문에 나만의 버전을 생성하고 관리할 수 있으며 즉각 동기화의 의무성이 없다.
- 이렇게 개발한 것을 merge를 통해 프로젝트 등을 발전시킬 수 있다.
용어 정리
- commit: 버전의 단계. 필요 기능을 개발 했을 때, 혹은 수정 했을 때 등 기록해야 하는 분기점을 표시하는 역할을 하기도 한다.
- staging: commit을 통해 버전을 관리할 파일들이 있는 곳(가상)을 stage라 하고 이런 장소에 파일들을 올리는 것을 staging이라고 한다.
- branch: 작업의 갈래. 필요한 기능을 개발하거나 수정할 때 다른 작업과 동시에 진행된다면 문제가 생길 수 있다. 이런 점을 막기 위해 branch라는 가지를 나눠 개발하고 추후 합치게 된다.
- merge: 위의 branch를 나눠 개발한 것들을 합치는 것을 merge라고 한다. 이것에는 3가지의 방법이 있다.
- 3-way: 두 브랜치의 가장 앞에 있는 커밋 내용을 합쳐 하나의 브랜치에 새로운 커밋으로 남기는 것
- fast-forward: 브랜치를 나눴으나 다른 브랜치에서 새로운 커밋이 존재하지 않을 때 뻗어나온 브랜치를 기존 브랜치에 붙여놓는 것
- rebase: 뻗어나온 브랜치에 기존 브랜치의 최신 내용을 모두 덧씌워서 커밋들을 그대로 기존 브랜치 앞단에 붙이는 것
Git Workflow
개념
Workflow는 단어의 조합만으로 보면 일+흐름 으로 일의 흐름 이라는 뜻입니다. 하지만 우리가 이 단어를 쓰는 곳이 Git인 만큼 버전 관리 시스템을 이용하는 상황에서 이를 원활하게 사용하기 위해 필요한 흐름을 제어하는 방법, 즉 규칙을 정해둔 것이라고할 수 있습니다.
여기서 Git Workflow는 Git을 활용해 어떤 방식으로 개발을 하는지 규칙을 정한 것이라고 할 수 있습니다.
방식
이런 git workflow의 방식에는 크게 3가지가 있고 각각의 간단한 특징을 정리해보면 아래와 같습니다.
- Git flow: 메인 2개, 서브 3개 총 5개의 브랜치!
- Github flow: 브랜치 1개에 유동적 브랜치 물리기!
- Gitlab flow: 브랜치 3개!
Git flow
2개의 메인 branch인 master와 develop, 3개의 보조 branch인 feature, release, hotfix가 있습니다.
각각의 역할을 적어보자면
master: 실제 제품 등 프로젝트의 배포버전을 위해 만들어져있는 출시버전을 커밋하기 위해 존재
develop: 실질적인 개발이 이뤄지는 branch. 특정 기능이 구현 되거나 디버그 등의 문제 해결을 했을 때 마다 이 branch에 합친다.
feature: 프로젝트의 기능 개발을 위해 생성된 branch. devolop 브랜치에서 branch를 분리해 필요한 기능들을 개발 하고 개발이 완료 되면 다시 합친다. 하나의 기능에 여러가지 기능이 필요하거나 여러 기능을 동시에 개발한다면 feature branch가 여러개가 될 수 도 있다.
release: master 브랜치에 들어가기 전에 준비 단계를 위한 branch 입니다. 여기서 출시 전에 버그 수정, 문서 수정 등 출시 전에 최종 점검을 하는 단계로 한 번에 몰아서 merge를 진행하게 되면 충돌 가능성이 올라가기 때문에 중간에 따로 빼서 정리를 하는 branch라고 할 수 있습니다.
hotfix: master branch에 올려져있는 출시 버전에 발생한 긴급한 오류를 수정하기 위해 만들어지는 branch로 출시버전을 이 branch에서 수정하고 master와 develop에도 병합해 반영한다.
이 그림에서 역할을 더 자세히 알 수 있는데요, master 브랜치에서 배포되어있는 0.1 버전과 같은 내용을 dev 브랜치에 가져와서 feature 브랜치로 기능 개발을 진행하고 도중에 발생한 오류사항을 hotfix 브랜치에서 수정하고 이를 master와 develop 브랜치 양쪽에 병합을 진행합니다.
그런 와중에도 feature 브랜치의 개발은 계속 진행되고 있네요!
하나의 feature 브랜치가 개발이 되어 develop 브랜치에 병합하고 해당 버전을 release 브랜치에 옮겨 배포 준비를 합니다. 해당 과정에서 수정사항들이 있다면 수정 후 develop 브랜치에 반영하고 수정이 끝났다면 master 브랜치로 변합하며 배포를 진행합니다. 이런 과정들을 계속 반복하며 프로젝트를 발전해 나아가고 있는 모습입니다!
장점
참.. 복잡하죠? 하지만 이런 구조를 통해 프로젝트의 흐름 구분이 수월해지고 마스터 브랜치의 버전 태그를 이용해 배포 버전 구분이 수월합니다. 또한 develop 브랜치가 있기 때문에 개발 진행 정도 파악도 쉽고 브랜치별 역할 구분으로 빠른 파악에도 도움을 줍니다.
단점
하지만 브랜치 자체가 많은 만큼 복잡하고 관리에 어려움이 생길 수 있습니다. 또한 이런 flow에 익숙하지 않다면 적응에도 시간이 오래 걸릴 수 있으니 사전에 팀원들의 학습이 요하는 방법입니다.
Github flow
Github flow 부턴 내용이 많이 간단한 편입니다. Git flow는 실제적인 개발을 단계에 따라 분류하는 과정을 브랜치로써 구분을 하도록 하기에 다소 복잡하게 보이기도 하죠. 이런 문제때문에 좀 더 간편한 방식을 원하는 사람들이 있었기에 이와 같은 방식이 나오게 되었습니다.
Github flow는 master branch를 메인으로 하면서 작업용 브랜치를 필요에 따라 생성하며 버그 수정, 기능 개발 등을 진행하며 완료된 사항들을 master에 병합을 하며 master 브랜치를 발전 해 나아가는 방식입니다.
위의 사진과 같이 master 브랜치를 유지하면서 Bugfix, Feature 브랜치 등을 생성, 병합을 해 나아가고 있습니다!
특징
이때 중요한 부분은 Git flow와 같이 배포 브랜치가 구분되어 있지 않고 master 브랜치가 즉시 배포로 이어지는 형태이기 때문에 병합 시 항상 확인을 하고 병합을 진행해야 합니다. 이 뿐만 아니라 마스터 브랜치의 커밋은 해당 커밋의 내용을 알 수 있고 구분 가능하도록 명확하게 작성 해야 하며 이런 내용이 로컬 상에서만 존재하지 않도록 수시로 push를 하도록 합니다. Git flow는 여러개의 브랜치로 구분되어 있어 개발 완료 내용의 업로드가 수시로 필요하진 않지만 Github flow는 master 브랜치를 공용으로 사용하기 때문에 그렇다고 합니다.
또한 이런 병합 과정에 점검 사항이 있을 수 있기 때문에 pr(pull request)를 활용하는 것이 좋다고 합니다.
Gitlab flow
Gitlab flow는 위의 Github flow의 단순해진 구성을 보완해 제안된 방식입니다.
여기엔 master 브랜치와 production 브랜치가 있는데 간혹 이 사이에 pre-production 브랜치가 있기도 합니다.
이 flow에서는 master 브랜치에서 개발을 진행하는 것은 Github flow와 마찬가지로 feature 브랜치에서 개발, master 브랜치로 병합 과정을 반복합니다. 하지만 Github flow와 다른 부분은 실제 배포되는 부분을 production 브랜치로 분리해 내서 배포 전에 master 브랜치의 정보를 수정 보완하는 과정을 거칠 수 있도록 개발 버전과 배포 버전을 구분할 수 있도록 했습니다. (여러 글들을 살펴보니 master - production 또는 develop - master 식으로 브랜치를 구분하는데 역할을 위의 글과 같습니다!)
결론
Git은 개발과 협업을 하는 과정에서 버전별 관리의 필요성이 생겨 이런 버전 관리 시스템의 대표라고 할 수 있는 시스템이다.
Git Workflow는 이런 Git을 더 효율적으로 관리하기 위해 브랜치를 어떤 방식으로 사용해야 하는지에 대해 여러 방식으로 고안한 것이다.
