마이크로서비스를 위한 git branch 생성 자동화

서비스 branch 간의 의존성을 최소한으로 하고,
하나의 branch를 하나의 개별적인 레포지토리처럼 사용할 수 있는
branch 생성, 병합 전략을 만들어 보았다.

잘못된 점이나 추가할 사항이 있다면 가감없이 피드백 부탁드립니다!

 

먼저 일반적인 Branch 명명 규칙을 알아보자

 

1. Master Branch

레포지토리를 새로 만들면 가장 먼저 만들어지는 브랜치

Release(배포) 할 수 있는 브랜치의 이력을 관리하기 위한 최상위 브랜치로 사용된다.

즉시 배포 가능한 상태만을 관리한다.

 

2. Dev Branch

다음 출시 버전을 개발하는 브랜치

Master에서 분기되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.

일반적인 모놀리식 아키텍처에서는 이 브랜치를 기반으로 개발이 진행된다.

기능 개발을 위해서 Dev 브랜치에서 새로운 브랜치를 분기하고, 분기된 기능 브랜치를 Dev 브랜치와 병합을 하는 과정일 것이다.

하지만 마이크로서비스 아키텍처에서는 각 서비스별 브랜치가 Dev 브랜치의 역할을 겸하고, Dev 브랜치는 각 기능을 통합하는 역할을 맡을 수 있다.

따라서 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 'dev' 브랜치를 'master' 브랜치에 병합한다.

 

3. Feature Branch

기능을 개발하는 브랜치 

https://nvie.com/posts/a-successful-git-branching-model/

feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 'dev' 브랜치로부터 분기한다.

feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 주로 자신의 로컬 저장소에서 관리한다.

하지만 마이크로서비스 아키텍처에서는 하나의 기능(feature)이 하나의 dev로 분류될 수 있기 때문에 dev 브랜치로부터 분기하지 않고 자신만의 독립적인 branch를 생성하게 된다. 그래서 feature 브랜치에서 추가적인 feature 브랜치가 분기될 수 있을 것이다.

따라서 MSA에서의 feature 브랜치는 원격 저장소에서 관리한다.

(feature 브랜치 대신 service 브랜치라고 명명 하는것이 더 좋아보인다.)

---

Branch 생성, 병합 순서

1. feature(service) 브랜치들을 사용해 기능별 마이크로서비스 개발을 한다.
2. 이때 feature(service) 브랜치에서 추가적인 분기(feature2)를 통해 작업을 수행한다.
3. 작업이 끝나면 Local에서 개발한 feature2를 feature(service)에 병합(merge)한다.
4. 완성된 서비스(feature(service))은 dev 브랜치로 pull request를 보낸다.
5. dev 브랜치는 feature 브랜치와 병합(merge)한다.
6. dev브랜치에 feature 브랜치의 기능이 모여 하나의 버전이 만들어졌다고 판단되면 master 브랜치에 병합시켜 배포한다.

 

이러한 마이크로서비스를 위한 Branch 생성에서 주의할 점은 Branch가 독자적인 공간을 가지고 있어야 한다는 것이다.

모놀리식처럼 모든 기능의 파일을 각 브랜치마다 가지고 있으면서 추가적인 기능 개발을 하는것이 아니라,

기능 개발에 필요한 독립적으로 분리된 파일들을 branch 단위로 구분하려고 한다.

 

---

독립적인 브랜치 생성 스크립트

 

새로운 서비스 브랜치 생성 전에 master 브랜치와 dev 브랜치가 있어야 한다.

 

우리는 게시판 서비스와 유저 서비스를 제공하려고 한다.

게시판과 유저 서비스의 분리를 위해서 우선 브랜치부터 독립적으로 생성하고, 해당 브랜치에서 각각의 기능을 개발하려고 한다.

 

## 파일명 : make-branch.sh

#!/bin/bash

echo "Enter new branch name: "
read newbranch

git checkout --orphan $newbranch
git rm --cached -r .

find . \! \( -type d -name .git -prune \) \! -name make-branch.sh -exec rm -rf {} \;

echo " ========================================="
echo "| Deleting unnecessary function files ... |"
echo " ========================================="
commitmsg="init"

git add .
git commit -m $commitmsg
git push origin $newbranch

git switch dev
git pull origin dev
git merge $newbranch --allow-unrelated-histories
git push origin dev

git switch $newbranch
echo " =========================================="
echo "| Start developing on your new branch now! |"
echo " =========================================="

 

1. 새로운 브랜치명 (ex. feature/board) 을 입력한다.
   
   
2. --orphan 옵션을 통해 새로운 브랜치를 생성한다.
   --orphan 옵션은 checkout을 실행한 브랜치의 커밋내역을 가져오지 않는 옵션이다.
   따라서 커밋내역이 0인 상태에서 브랜치를 생성하게 된다.
   대신에 기존 브랜치에 존재하던 파일들이 새 브랜치로 와서 staged 상태에 올라가있다.
   
   
3. git rm --cached -r . 을 통해서 staged된 파일을 unstage 해준다.
   
   
4. find . \! \( -type d -name .git -prune \) \! -name make-branch.sh -exec rm -rf {} \;
   .git 폴더의 파일들과 make-branch.sh 파일을 남기고 모조리 지운다.
   .git을 지우면 깃허브와의 연결이 끊기고, make-branch.sh를 지우면 현재 실행중인 스크립트가 종료되어 브랜치가 제대로 생성되지 않기 때문이다.
   그리고 커밋을 공유하지 않기 때문에 기존 브랜치에서 필요없는 파일을 편하게 지울 수 있다.
   
   
5. 깨끗하게 정리된 새 브랜치를 원격 레포지토리에 push한다.
   
   
6. dev 브랜치로 이동해서 새 브랜치와 병합(merge)한다.
   새 브랜치에서 dev 브랜치로 pull request를 하기위해서 반드시 필요한 작업이다.
   (dev와 feature(service)의 연결에 필요한 작업)
   그리고 dev 브랜치의 병합 기록을 원격 레포지토리로 push한다.
   
   
7. 새 브랜치로 이동한다.
   이제 원하는 기능을 마음껏 추가할 수 있다.

 

 

내가 쓰려고 만든 branch 전략