이 글을 쓰게 된 이유
지금까지 프로그래밍을 5년이상 공부하며 여러 프로젝트를 진행하면서 겪었던 어려움을 해당 포스트를 통해 조금이라도 궁금증을 해결하면 좋겠다라는 바람에 글을 쓰게 됐습니다. 또한 개발을 시작한지 얼마 안된 사람들이 언어를 배우는데 급급하여 여러 강의를 듣고 프로젝트를 진행하는 것을 보았는데, 개인적인 생각으로 프로그램 언어를 배우고 실제 프로젝트에 적용하는 것도 중요하지만, 어떻게 협업을 하고 프로젝트 구조, 코드 구조에 대해서 고민하는 것이 더 중요하다고 생각합니다. 그래서 그 중, 협업에 대해서 제 경험에 빗대어 글을 써보려고 합니다.
시작하기 앞서
이런 분들에게 해당 포스트를 추천합니다
- git에 대해서는 알지만, 실제 프로젝트에 적용을 해보니 너무 어려운 점이 많아요!
- 프로젝트를 진행하면서 git을 사용하고자 하는데 어떻게 사용해야 할지 모르겠어요!
- 어떤 git 전략을 사용해야할지 궁금해요!
이런 분들에게는 앞선 공부가 필요합니다
- git이 무엇인가요?
- git branch에 대한 이해도가 떨어져요!
git 이란?
우선 git flow에 대해서 설명하기 전에, git에 대해서 알고 있어야 합니다.(이하 깃) 우선 깃이란 분산 버전 관리 시스템 중 하나로 svn과 더불어 오늘날 가장 많이 사용하고 있는 시스템입니다. 깃은 여러명의 사용자들에게 파일에 대한 버전 및 히스토리를 관리할 수 있게 해줍니다. 그렇다면 깃은 왜 필요할까요? 실제 우리가 프로젝트를 진행하면서 여러 사람들이 파일을 공유하거나 소스 코드를 공유하면서 오류를 같이 고민하기도 하고, 혹은 오류가 났을 때 코드 변경점을 확인하고 이를 통해 고치거나 여러명의 사람들이 함께 같은 파일을 공유하면서 협업을 하기도 하는데 이와 같은 작업을 깃에서 모두 할 수 있습니다.
가장 중요한 것은 깃의 명령어를 알고 이를 쓰는 것 또한 중요하지만 위에서도 말씀드렸듯이, 구조와 개념이 가장 중요하고 이를 모두 이해하는 것이 그 언어, 시스템을 의도에 맞게 100% 사용할 수 있기 때문에 깃에서 가장 중요한 개념인 local repository와 remote repository에 대해서 말하고자 합니다. 사용자들은 각각 local repository라는 개인 로컬 저장소를 가지고 있습니다. 여기서 자신의 파일을 저장하고 이를 깃이 추적합니다. 이 과정을 통해 히스토리(버전)을 관리할 수 있게 됩니다. 그렇다면 remote repository가 하는 일은 무엇일까요? 바로 여러 사용자들의 파일 버전을 맞추는 작업을 합니다. 각각의 사용자들은 local repository에서 작업을 마치고 이를 remote repository에 업로드하여 파일을 공유하게 됩니다. 그래서 이 개념을 가지고 명령어를 배운다면 각각의 명령어들이 무엇을 의미하는지 쉽게 파악할 수 있으며, 개념을 헷갈리지 않기 때문에 찾아보지 않아도 자연스럽게 체득하실 수 있습니다.
git flow란?
그렇다면 git flow란 무엇일까요? 간단하게 말하자면 브랜치 관리 전략입니다. 각각의 브랜치는 각 브랜치의 성격에 맞는 Action을 요구합니다.
- 주요 브랜치
-
master브랜치는 깃의 기본 브랜치로 배포준비된 코드를 커밋하여 해당 브랜치로 커밋이 생기면 자동으로 빌드하여 배포까지 되는 git hook 스크립트를 사용하기도 하여 자동 CI/CD(Continuous Integration/Continuous Delivery)를 구현하여 사용합니다. -
develop브랜치는 배포하기 위해 작업해야되는 코드로 프로젝트에서 개발자들이 함께 작업하는 브랜치로 해당 브랜치에서 작업이 끝나면master로 병합하고 태그를 답니다.
-
- 보조 브랜치
-
feature브랜치는 기능을 개발하는 브랜치로 프로젝트에서 구현하고자 하는 기능 중 한가지를 구현할때develop브랜치에서feature-*브랜치를 생성하며, 해당 기능 구현이 완료되면 다시develop브랜치로 병합을 하게 됩니다. -
release브랜치는 말 그대로 실제 배포할 상태가 된 경우develop브랜치에서release-*브랜치를 생상하며,feature브랜치에서 각각의 기능이 완성되어develop브랜치에 병합이 되고, 이상이 없을 시에release브랜치로 병합합니다. 해당 브랜치에서는 릴리즈 준비 즉, bug-fix도 포함하여 브랜치를 관리합니다. -
hotfix브랜치는 모든 것이 완료되어master브랜치에 병합이 되고, 이후 버전을 준비하려고 다시develop브랜치에서 작업을 하던 도중 심각한 버그를 발견했을 때,master브랜치에서hotfix-*브랜치를 생성하여 해당 버전 태그로부터 버그를 고친 후 다시master로 병합을 하게 됩니다. 또한 해당 사항이 추후 개발 과정에도 포함이 되어야 함으로develop브랜치에서 해당 커밋내역을 가져옵니다.
-
위와 같이 브랜치를 관리하면 사용자 간의 협업에서부터 코드, 파일을 효율적으로 관리하며 충돌을 줄이고 오류 발생시에도 추적이 쉬우며 배포시에도 master브랜치에서 자동으로 빌드 및 배포 설정을 통해 개발 이외의 드는 시간을 아낄 수 있습니다.
글을 마무리하며
제가 실제로 사용하고 있음에도 불구하고 글로 나타내려고 하니 굉장히 두서 없이 쓴 것 같고 아직은 저도 많이 부족하다는 것을 느낍니다. git-flow에 대해서 포스팅을 하긴 했지만 사실 이는 모든 프로젝트에 적합하다고 할 수 없습니다. 처음 git-flow를 고안한 사람인 Vincent Driessen도 이는 솔루션이 아닌 그저 간단한 룰이며 언제든 변경할 수 있다고 말했을만큼, 우리 GDSC 여러분들도 자신들의 팀 혹은 자신이 속해있는 프로젝트에서 어떤 식으로 깃을 활용할지 고민하면 개발 도중에 맞닥뜨리는 여러 이슈에 대해서 좀 더 기민하게 대응할 수 있을 것이라 생각됩니다.
git-flow 이후에도 github-flow, gitlab-flow 등등 여러 단점을 보안하고 프로젝트 성격에 맞는 다양한 전략들이 나와 있으니 확인해보면 이 또한 도움이 많이 될 것이라고 생각합니다. 글을 마무리하며 현재 데이터 분야에서 NLP쪽을 담당하시는 분에게 깃을 어떻게 사용하는지 여쭤본 대답으로 글을 마무리하고자 합니다. data-ml 분야를 담당하시는 분들에게도 이렇게 깃을 사용하면 괜찮지 않을까 생각이됩니다.
