03. 브랜치 전략

# What?

- 분산버전관리 전략

 

# Why?

- 운영 사이트용, 테스트 사이트용 버전을 나눠서 운영할 필요가 있음
(운영 사이트에 변경된 소스를 바로 적용해서 테스트하면 오류 있을 경우 치명적인 손해로 돌아올 수 있음, 안전하게 테스트용 사이트에서 확인해보고, 운영 사이트에 반영하는게 안전)

 

-  기능 단위별로 개발

  기능 단위별로 브랜치를 따로 따서 관리하면 여러명이 개발할 때도 용이하고, 한 브랜치를 오래 붙잡고 작업하지 않기 때문에 서로 작업한 결과물을 합칠 때 충돌이 덜 남(짧은 주기로 개발해서 자주 소스를 합치면 서로 싱크로율이 많이 어긋나지 않음)

 

# How?

브랜치명	용도
master	운영 브랜치
hotfix	운영 사이트에 발생한 오류를 급하게 수정해야할 때
dev	개발 브랜치
release	테스트 브랜치(개발 브랜치 -> 운영 브랜치로 배포 전 테스트)
feature	기능 단위 브랜치 ex. 게시글 삭제 기능 브랜치, 게시글 생성 기능 브랜치 등

명령어	용도
git checkout -b [브랜치명]	새로운 브랜치 만들기
git checkout [브랜치명]	해당 브랜치로 이동
git merge [브랜치명]	해당 브랜치의 소스를 현재 내가 있는 브랜치와 합치기

1) 프로젝트 생성 후 git bash 켜서 해당 프로젝트 폴더로 이동한 후 git 세팅(기본이 master 브랜치에서 시작)

git init

2) 개발 브랜치 생성

git checkout -b dev

3) 기능 브랜치 생성

git checkout -b feature/[write feature name]

4) 기능 개발이 완료되면 테스트 후 개발 브랜치에 합치기

(더 개발할 기능이 있으면 합친 후, dev 브랜치에서 다시 feature 브랜치를 따서 개발 완료 후 dev 브랜치에 합치기를 반복)

git add *
git commit -m "write what you do" // ex. git commit -m "add header"
git checkout dev
git merge feature/[~~~~]

5) dev 브랜치에서 release 브랜치를 따서 release 브랜치 소스를 테스트용 사이트에 반영하기, 버그 있으면 고치기

git checkout -b release-[next version number] // ex. git checkout -b release-1.0
git push origin release-[next version number]

6) 테스트 후 문제 없으면

-> dev 브랜치로 이동 후 release 브랜치 합치기

-> master 브랜치로 이동 후 dev 브랜치 합치기

-> master 브랜치 소스를 운영 사이트에 반영하기

git checkout dev
git merge release-[~~~~]
git add *
git commit -m "~"
git push origin dev

git checkout master
git merge dev
git add *
git commit -m "~~~~"
git push origin master

7) 버전 태그 달아주기(이래야 버전관리 용이)

git tag v[version number] // ex. git tag 1.0
git push origin v[version number]

 

* 운영사이트에 반영했는데 버그가 있다면

-> master 브랜치에서 바로 hotfix 브랜치를 딴 후 버그 수정 작업

-> master 브랜치로 이동해 hotfix 브랜치를 merge

-> dev 브랜치로 이동하여 dev에도 hotfix 브랜치를 merge해주기

 

* 위 브랜치들을 그림으로 보기