회사에 입사해, 서비스의 프론트 코드들을 둘러보며 개발을 시작했고, 현재 실 서버에 핫픽스 부분들을 배포하였다.
우리 팀은 현재 Git-flow 전략을 베이스로 관리하고 있는데, 막연한 이해정도만 갖고 있었기에 이 참에 정리하려한다.
Git?
깃을 사용해보지 않은 학생이나, 이제 처음 접해본 사람들은 생소할 수 있다.
나도 1년전까지만 해도, 혼자서 공부를 계속 해왔고 대학 과제나 다양한 부분들을 로컬외의 환경에서 사용 할 이유가 없었기 때문이다.
하지만 소프트웨어를 다루는 사람으로써, VCS를 다룰줄 아는 것은 필수라고 생각한다.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. -git-scm.com
Git은 오픈소스 VCS, Version Control System이다. 즉, 다양한 규모의 프로젝트를 동료들과 협업할 때, 꼬일 수 있는 버전들을 컨트롤하는 시스템인 것 이다.
동시간대에 같은 코드를 작업하고 있다 생각해보자.
다행스럽게 다른 코드들의 작업이 들어가면 다행이지만, 동료가 일부 모듈들을 작업하거나, 혹은 동일 코드를 수정하여 내가 짠 코드들이 준구난방으로 섞이게 된다면?
이 모든 과정들이 사실 git에 익숙하지 않은 상태로, 협업을 진행할 때 크게 느끼게 된다. 나도 1년전 간단한 토이프로젝트를 2인으로 진행하게 될 때, 둘다 git에 익숙하지 않아 곤혹스럽기도 하였다...
Git 브랜치 전략
본 포스트에서는 git-flow를 제외한 다른 기본적인 git 명령어들이나 용어들을 크게 정리하지 않을 것이다.
많은 사이트들이 git의 명령어들을 다루며 어떻게 사용하는지에 대해 설명하고 있으니, 선행적으로 익히고 와도 좋을 것 같다.
소스코드를 동료들과 함께 작업할 때, 같은 코드를 두고서 변경점을 계속 체킹하며 작업을 하는 것은 너무 많은 시간을 소요한다.
즉, 브랜치는 독립적인 작업을 진행하기 사용된다. 주 라인을 나둔 채로, 내 작업을 자유롭게 할 수 있는 공간인 것 이다.
이러한 브랜치들을 잘 사용하고자, 팀의 색깔에 맞게 작업하기 위해 다양한 전략들을 참고하고 도입한다.
가장 핫한 해외 토픽 중 하나도, 다양한 브렌치들이 필요한 git branch stratagies인지, 혹은 하나의 main 브랜치에 작업을 넣는 trunk-based development인지에 대해 다양한 의견을 나누기도 한다.
그렇다면, 가장 인기있고 많이 도입되는 몇몇 브랜치 전략들을 살펴보자.
GitFlow
요즘 프로젝트들에는 다소 복잡하다고도 평가를 받는 git-flow 전략은 몇가지의 주요 브랜치들을 갖고있다.
Master: 실 서버에 배포되는 브랜치이다.Develop: 개발자들이 지속적인 개발을 진행하는 브랜치이다.Feature:develop브랜치로부터 각feature단위로 작업을 진행하는 브랜치이다.Release: product의 릴리즈를 위한 브랜치이다. 정기적으로 (weekly or monthly) 릴리즈를 하는 서비스를 위한 브랜치로, develop으로 부터 브랜치가 파생되어 릴리즈가 된 이후에는master와develop에merge된다.Hotfix: 주로 버그가 발생하였을 때 활용하는 브랜치로, 개발자들이develop브랜치에서 작업을 계속 할 수 있도록 한다.
장단점
브랜치들이 평행하게 관리되는 만큼, 병렬적인 작업과 그에 맞은 안정적인 릴리즈, main 브랜치에 있는 코드의 안전성 및 개발자들의 개발 관리가 편리해진다.
프로젝트에 참여하는 개발자가 여려명일때, 우선 순위가 높은 작업들을 할당받아 병렬적으로 작업을 진행하고, 다음 릴리즈때까지 개발하여 develop브랜치에 반영, 반영된 develop 브랜치를 바탕으로 release가 나가고 master에 merge된다.
분명한 단점도 존재한다. git-flow 특유의 복잡성 때문에 develop과 release 사이클에서의 소요 시간이 늘어난다. 지속적인 integration 과 delivery가 일어나는 서비스라면 어울리지 않을 것 이다.
Setup
- macOS brew
$ brew install git-flow-avh간혹 옛 버전들의 git이 사용 될 수 있다. 이때는 다음과 같은 명령어로 PATH 환경변수를 수정해주자
$ brew install git
$ echo "export PATH=/usr/local/bin:$PATH" >> ~/.bash_profilegit-flow 사용을 위해 초기화를 진행해야한다.
git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []앞서 언급한 브랜치들에 대한 초기 세팅이 이루어진다.
명령어
feature브랜치 시작하기
git flow feature start 브랜치명develop으로 부터 feature 브랜치를 생성한다.
feature브랜치merge하기
git flow feature finish 브랜치명해당 feature 브랜치를 develop에 merge한 후, 삭제한다. develop으로 이동한다.
origin에push하기
git flow feature publish 브랜치명해당 feature 브랜치를 원격저장소에 push한다.
origin에서pull하기
git flow feature pull origin 브랜치명해당 feature 브랜치를 origin으로 부터 불러온다.
release브랜치 시작하기
git flow release start RELEASE [BASE]커밋의 해쉬태그를 [BASE]에 입력하여 커밋으로 부터 릴리즈 브랜치를 시작할 수 있다. 단, 해당 커밋은 반드시 develop에 존재해야한다.
git flow release publish RELEASE릴리즈 브랜치가 생성된 이후에는, 다른 개발자들이 작업 내용을 반영 할 수 있도록 원격 저장소에도 publish하자.
release완료하기
git flow release finish RELEASEgit push --tags릴리즈 브랜치를 완료하게 되면, master와 develop에 merge된다. 이때 해당 릴리즈 명으로 tag가 생성되므로, 잊지말고 push하자.
해당 릴리즈 브랜치는 삭제된다.
hotfix브랜치 시작하기
git flow hotfix start VERSION [BASENAME]버전 인수는 핫픽스 릴리즈 이름으로 한다.
hotfix브랜치 완료하기
git flow hotfix finish VERSION핫픽스 브랜치를 완료하게 되면, master와 develop에 merge된다. 추가적으로, master의 병합 부분은 핫픽스 버전으로 태그된다.
Github Flow
Github Flow는 다양한 버전을 다루지 않는 팀에게 더욱 효과적인 심플한 gitflow 전략의 대안이다.
가장 큰 차이로는 master 브랜치에서 직접적으로 feature 브랜치를 생성, 이후 merge된다는 것 이다.
장단점
develop 브랜치가 없는 만큼, 개발 사이클이 짧고 빠르며 Agile한 팀에게 더욱 어울린다.
빠른 피드백이 가능하며 이슈를 빠르게 해결 할 수 있다는 장점이 있다. develop 브랜치의 부재 덕에 배포 또한 빠르게 이루어진다.
규모가 작은 팀과 웹 애플리케이션에 어울리며, 한 버전만을 다룰수록 효과적이다.
하지만 develop 브랜치의 부재로, 이슈와 버그에 민감하고 안정적이지 않은 코드로 이루어질 수 있다. develop과 production 역할을 모두 행하는 master 브랜치가 어수선해질 수 있다.
점진적인 조직이고, 서비스의 규모가 커지고 인원이 충원 될 수록 해당 전략은 비효율적이다. master 브랜치에 직접적인 작업이 merge되려는 작업이 많을수록 다양한 conflict를 야기시킬 수 있기 때문이다.
GitLab Flow
비교적 너무 간단한 Github Flow의 단점을 보완하고자 나온 방법이다.
이때, master 기존의 develop과 비슷한 역할을 하며, 스테이징 서버에 배포되있다.
pre-production은 master와 production 브랜치의 중간다리 역할로, 테스트 서버에 배포하는 브랜치이다.
production은 기존의 master와 비슷하게, 실서버에 배포되는 브랜치이다.
장단점
master 브랜치에서의 작업 내용들이 단계적으로 pre-production과 production을 거치며 배포되기 때문에 기존의 Github Flow보다 안정적이며 Git flow보다 간편하고 싸이클이 빠르다.
따라서 동일하게 정기적인 릴리즈가 아닌, 지속적으로 릴리즈가 일어나는 경우 도입하기 좋다.
Trunk-based Development
중앙 집권적인 브랜치(trunk)에 지속적인 merge를 하는 전략으로, 모든 개발자들은 공유된 trunk (master or main)에 직접적인 커밋을 진행한다.
장단점
Continous Integration(CI)와 Continous Deployment(CD)에 적합한 전략으로 직접적인 커밋이 하나의 trunk에서 이루어지기 때문에 이러한 과정들이 빠르고 간결하다.
하루에 하나 이상의 병합을 trunk에 이루는 조직일 수록 더욱 적합하다.
개발자들은 로그들을 통해 어떠한 작업이 이루어졌는지 확인하기 쉽고, 장수하는 브랜치들에 대해 껄끄럽게 생각하는 개발자들을 위해 좋은 대안이다.
하지만 그만큼 개발자들의 작업이 직접적으로 trunk에 commit되므로, 숙련된 개발자 (시니어 이상의 개발자)가 아닌, 주니어 개발자들과 함께 작업하는 프로젝트에서는 비효율적일 수 있다.
(코드 리뷰 및 커맨트 등을 commit 및 push 된 이후에 진행한다면, 모든 작업들이 중단되거나, commmit이 취소되거나, 혹은 작업이 더욱 진행되었을 경우, rebase해야 할 수도 있기 떄문에)
자기가 속한 조직에 알맞은 전략을 선택하기 위해, 그리고 알맞게 커스터마이징 하기 위해서는 다양한 전략들을 공부하고, 생각해보는것은 중요한 것 같다.
장시간 혼자 작업도 해보고, 소규모 팀으로 작업도 해보고, 회사에서 운영되고있는 서비스를 개발 및 유지보수 하면서, 경험을 통해 체화하고자 한다.
또한 미래에 시니어 개발자가 되어 혹은 내가 몸담고 있는 Frontend의 세팅을 진행하게 된다면, 이러한 전략들을 잘 도입하여 동료 개발자들과 함께 효율적인 협업을 진행 할 수 있어야 할 것 같다.
'Software Engineering' 카테고리의 다른 글
| [Design Pattern] 의존성 (Dependency) (0) | 2022.10.09 |
|---|---|
| [Javascript] Class vs Factory Function (2) | 2022.09.24 |
| 성능을 위한 프론트엔드 설계와 코드 - 1 (0) | 2022.08.28 |
| Quality Assurance (QA: 품질보증) (0) | 2022.08.26 |
| 함수형 프로그래밍 (Functional Programming) (0) | 2022.08.21 |