병합과 재정렬은 대개 한 Topic(작업 단위)의 작업이 끝난 다음, 작업 내용을 Master branch에 반영해야 할 경우 수행하는 작업입니다.

새로운 Topic에 대한 작업을 할 때는 대개 Master Branch에서 새로운 Branch를 따서 작업한 뒤, 나중에 다시 Master Branch에 합치는 순으로 작업을 진행합니다.

병합과 재정렬에 대한 이해는 GIT으로 작업하기 위해 PM 뿐만 아니라 팀원도 알고 있어야 합니다. 병합과 재정렬에 관련된 작업 흐름을 어느 정도 이해하고 있어야 불필요한 추가 작업을 막을 수 있고, '이렇게 해도 되는데 왜 꼭 이렇게 하라고 하는거지?'라는 불만을 갖지 않게 될테니까요.^-^

특정 Commit을 선택해서 반영하기 - cherry-pick

다른 Branch에 있는 Commit을 선별적으로 현재 Branch에 반영하기 위한 명령어입니다. Cherry-pick이라는 이름에서 뭐에 쓰는 건지 예측이 될 것입니다.

체리 나무에 달려 있는 체리를 하나씩 골라 따듯이, 커밋들이 달려 있는 커밋 나무(?)에서 필요한 커밋들을 하나씩 선별해서 가져 오기 위한 명령어가 바로 cherry-pick입니다.

이 때, 현재 Branch는 작업 내역을 반영할 Branch(대개 Master)여야 하고, 가져오려는 Commit이 여러개인 경우 먼저 작성한 Commit부터 순서대로 가져와야 합니다.

Cherry-pick은 엄연히 말하면 Commit을 가져 오는 것이 아니라, 가져올 Commit과 같은 Commit을 새로 만들어서 현재 Branch에 덧붙이는 작업입니다. 즉, 현재 Branch에 붙는 Commit은 Commit ID가 달라집니다.

왜냐하면 A를 X로 바꾸는 Commit과 B를 X로 바꾸는 Commit은 작업 내용이 서로 다른 Commit이기 때문입니다. 설명이 복잡해 졌는데, 이해가 잘 안간다면 다음 한 문장만 기억해 두면 됩니다.

'Cherry-pick은 Commit을 새로 하는 것과 같다.'

여러 개의 Commit을 반영하기 - rebase

Rebase는 Cherry-pick과 유사하지만, 여러 개의 Commit을 동시에 다룰 수 있습니다. 즉, Cherry-pick으로 하는 작업은 Rebase 명령어로도 할 수 있습니다. 다만, Rebase는 여러 개의 Commit을 하나로 합치거나, 특정 Commit을 건너 뛰는 등 보다 복잡한 작업을 수행할 수 있습니다.

여러 개의 Commit을 순서대로 가져와서 반영하기

대상 Branch의 변경 사항을 모두 가져와서 현재 Branch에 반영하려 할 때 다음과 같은 명령어를 사용합니다. 

즉, 현재 Branch와 대상 Branch의 공통 조상부터 대상 Branch의 마지막 Commit까지의 모든 Commit을 순서대로 하나씩 가져와서 현재 Branch에 덧붙입니다.

결과적으로, 대상 Branch는 변경되지 않고 현재 Branch에만 새로운 Commit이 생성되어 덧붙여집니다.

Commit의 순서를 재정렬하고 첨삭하기

Rebase 명령에 -i(interactive) 옵션을 덧붙여 사용하면 Commit들의 순서를 바꾸고 첨삭하거나, 몇 개의 Commit을 하나로 합치는 등의 작업을 수행한 뒤 가져올 수 있습니다.

Rebase 명령과 -i 옵션의 조합은 '리베이시'라고도 불리우며, 병합 작업 뿐만 아니라 현재 Branch에서 최근에 작업한 몇 개의 Commit들을 편집하고자 할 때도 유용하게 사용할 수 있습니다.

예를 들어, 다음과 같이 입력하면 현재 Branch의 HEAD로부터 3개의 Commit들을 편집할 수 있습니다.

이 때, Rebase 작업 이후 Commit들은 Cherry-pick과 마찬가지로 모두 ID가 바뀝니다.

쉽게 생각해서 위 명령은 HEAD로부터 3개의 Commit들을 현재 Branch에서 모두 '들어낸 뒤', 순서를 바꾸거나 합치는 등의 작업을 하고 다시 하나씩 새로 Commit하는 것입니다.

'리베이시' 명령은 개발을 진행하면서 은근히 많이 사용되므로 눈여겨 보는 것이 좋습니다. 특히 위에서 예로 든 명령의 경우 심심치 않게 자주 사용하게 될 것입니다.

두 개의 Branch를 하나로 합치기 - Merge

3-Way Merge

3-Way Merge란 하나의 Branch를 다른 Branch에 합치는 작업을 의미합니다. 엄연히 말하면 부모 Commit이 둘 이상인 새로운 Commit을 만들어서 현재 Branch에 덧붙이는 작업입니다.

옵션으로 넣은 --no-ff 는 Fast-forward Merge가 가능하더라도, 무조건 3-Way Merge를 수행하라는 의미입니다.

3-Way Merge 작업을 수행하고 나면 합칠 Branch에서 가져온 Commit이 몇 개 였던지 간에 현재 Branch에는 딱 하나의 Commit만 새로 생성됩니다. 따라서, Merge를 취소하고 싶다면 새로 생성된 Commit만 삭제해 주면 됩니다.

Fast-forward Merge

Fast-forward Merge는 합칠 Branch가 현재 Branch와 분기된 이후, 현재 Branch에 새로 생성된 Commit이 없을 경우 현재 Branch를 가리키는 HEAD를 합칠 Branch의 마지막 Commit으로 옮김으로써 Merge를 수행하는 방법입니다.

뭔가 복잡한 설명이 되었는데요, 그림을 보면서 설명해 드리도록 하겠습니다.

( 그림 출처: http://www.deferredprocrastination.co.uk/blog/2012/git-un-merge/ )

왼쪽 그림은 Commit B의 위치에서 develop branch를 새로 만든 뒤, 이후 develop branch에서 C, D, E의 세 개 Commit을 작성한 상황을 나타내고 있습니다.

develop branch에서 세 개의 Commit을 새로 작성하는 동안, master branch에는 새로운 Commit이 하나도 추가되지 않았습니다. 이 상황이 바로 Fast-forward Merge가 가능한 상황입니다.

여기에서 Fast-forward Merge를 수행하면 3-Way Merge처럼 두 개의 조상을 갖는 새로운 Commit을 만들어서 master에 덧붙이는 것이 아닌, master branch를 가리키는 Commit Pointer를 E Commit으로 옮기는 것으로 Merge를 끝마치게 됩니다.

즉, 결과적으로 Master branch에서 C, D, E Commit을 새로 작성하고 E commit에 develop이라는 새로운 이름을 붙여 준 것과 같아집니다.

Fast-forward Merge는 수행 속도가 빠르고 불필요한 Branch를 없애 주는 역할을 하지만, 두 개의 branch의 구분이 사라지기 때문에 프로젝트 관리 면에서 모호함이 발생할 수 있습니다. (위 그림을 보면 master branch와 develop branch의 구분이 사라졌음을 알 수 있습니다.)

Merge 명령에 별도의 옵션을 주지 않으면 기본적으로 Fast-forward Merge를 수행합니다. 단, Fast-forward Merge가 불가능한 조건일 경우 3-Way Merge를 수행합니다.

경우에 따라서 작업 기록을 남겨 두기 위해 Fast-forward Merge를 수행하지 말아야 될 경우가 있습니다. 이 경우 --no-ff 옵션을 주어서 3-Way Merge를 수행하면 됩니다.

Rebase VS Merge

Rebase와 Merge 모두 새로운 작업 내용을 Master branch와 합치는 데 사용할 수 있는 유용한 명령어입니다. 다만, 이 둘을 각각 언제 사용해야 할 지 잘 모르겠다면 다음 문장을 기억하고 있으면 됩니다.

'Merge는 Commit ID가 보존되고, Rebase는 새로운 Commit이 생성되므로 Commit ID가 바뀐다.'

그래도 잘 모르겠다면 PM에게 물어보면 됩니다. PM이 작업을 진행하는 스타일에 따라서 작업 내용을 Main stream branch에 반영할 때 Merge를 사용할 지, Rebase를 사용할지 달라지기 때문입니다.

GIT에 처음 입문하면 Commit ID가 달라지던 말던 작업 내용이 잘 반영되면 그만이지, 뭐가 중요하냐고 생각할 수도 있습니다. 하지만, 프로젝트의 규모가 커지면 이야기가 달라집니다.

원격 저장소에는 가급적 같은 작업을 수행한 Commit이 두 개 이상 존재하지 않도록 유지해야 합니다. 같은 작업 내용을 갖는 Commit이 두 개 이상 존재하면 지저분해지고, 프로젝트 관리상 좋지 않기 때문입니다.

역사가 오랜(?) 오픈소스 작업을 할 때는 Commit Log에 작업을 위한 정보가 담겨 있는 경우가 많고, 따라서 오랜 옛날의 Commit Log를 뒤져야 하는 경우가 많습니다. 이럴 때 같은 작업을 수행한 Commit이 둘 이상이라면 그것들을 모두 살펴봐야 하는 불상사가 발생합니다.

일반적으로, 로컬 저장소에서 병합하고 Push하는지, 혹은 작업 Branch를 Push하고 병합하는지에 따라 무엇을 사용할지가 결정됩니다.

핵심은 같은 작업을 하는 Commit이 둘 이상 발생하지 않도록 하는 것이므로, 다음과 같이 구분해서 사용하면 됩니다.

Rebase

로컬 저장소에서 작업을 위해 개인적으로 만든 Branch를 Main stream branch에 반영하여 Push 하기 위해 사용합니다. 로컬에 개인적으로 만든 Branch는 Push 이후 정리를 하면서 대개 삭제합니다. 대개 Hotfix와 같이 단기간에 끝나는 Topic의 경우 이 방법으로 작업합니다.

Merge

로컬 저장소에서 분기하고 작업한 Branch를 리뷰 등을 위해 원격 저장소에서 Push한 뒤, Review가 끝나고 PM이 Main stream branch에 병합하는 순서로 작업을 진행할 때 사용합니다. Branch가 그대로 유지되기 때문에 나중에 추가 작업을 해야 할 경우나, 큰 규모의 Topic인 경우 이 방법으로 작업합니다.

[출처] https://www.tuwlab.com/ece/22218

Last Christmas I bought my wife and myself a Synology NAS to store our pictures on. Given that I’d spent a lot of time over the last few years working on Git LFS, I always thought it would be pretty cool if you could use the NAS as an LFS server.

Like everything else these days, the thing can run apps. I looked around for what it would take to make an app for it and what I found seemed to be mostly a bunch of flaming hoops to jump through. I’m pretty lazy, so I dropped it.

The other day I was checking out Home Assistant and noticed it could be installed on the Synology via Docker. Wait … what? You can run Docker on it‽ Far out! It is Linux, so I guess that makes sense. Now it should be easy to set up an LFS server on it. We have a reference server that’ll do just fine for this.

To get running, first install the Docker app from Package Center. Start the app and head to the Registrytab. It’s hooked up to DockerHub by default. The search seems to love returning results for things you didn’t ask for, so it’s best to just search for rubyist. Searching for rubyist/git-lfs-server is far too specific, I guess, but that’s what you’re looking for. Click Download for download.

Once it’s downloaded, it’ll appear in the Image tab. Click Launch to launch.

This brings up the Docker app’s container wizard. It’s actually quite nice. Click the Advanced Settingsbutton. Set the following options in their respective tabs:

• Advanced Settings: Enable auto-restart
• Volume: Add a folder on the drive at a Mount Path of /var/git-lfs
• Network: Select “Use the same network as Docker Host”
• Environment: Configure any environment vars for the server

The full set of supported environment variables can be found in the lfs-test-server README, here are the ones you’ll need to set:

• LFS_HOST: The host name of your NAS
• LFS_ADMINUSER: The username of the admin user
• LFS_ADMINPASS: The admin password

When setting LFS_HOST you’ll need to include the port that the LFS server is running on, which will be ":8080". For example, "foobar.localdomain:8080".

Once you’re done there, close the advanced settings and click the Next button. You’ll see a summary of the config. Click Apply.

Your LFS server is now running! Configure LFS by adding the following to the .lfsconfig file in the root of your repo:

[lfs]
	url="http://foobar.localdomain:8080/rubyist/myrepo"

If you have questions, tweet at @rubyist, I might answer.

[출처] https://killring.io/post/synology-for-lfs/

NAS를 살 때 많은 고민을 하고 Synology 제품을 선택했다.

FTP 같은 기능은 당연한 것이고,

CloudStation 은 참 만족스러운 기능으로 사용을 했다.

최근에 주변 사람을 통해서 소스 형상관리툴 Git을 알게 되었다.

나의 NAS에서 Git을 설치할 수 있다는 것을 알게 되고는

구글링등의 많은 방법을 통하여 설치하는 방법을 알게 되었다.

이걸 정리를 해 놓아야지 다음에 다시 설치하더라고 유용할꺼 같아서 정리를 해 보았다.

● 설치 환경

Synology NAS DS212J

DSM 5.2

● 사용환경

Visual Studio 2013

● 설정방법

1.NAS에서 SSH서비스를 활성화해야 한다.

제어판에 들어가서 응용 프로그램란에 [터미널 및 SNMP]를 선택한다. 

SSH 서비스를 활성화 시켜준다. 

2.Git Server 설치

NAS바탕화면에 있는 패키지 센터를 실행해서, [모두] 또는 [유틸리티]화면을 열어보면 아래와 같이 Git Server라는게 보인다.

서버가 설치되기 전에는 버튼이 [설치]라고 되어 있어 설치하고 나서 보면 아래와 같이 [열기]로 보여진다. 

Git Server 설치 후 설치됨 메뉴를 선택해보면 아래와 같이 설치가 되었음을 알 수가 있다.

Git Server를 선택하여 들어가서 Git Server 서비스를 활성화 시켜준다. 

3.NAS에 사용자 계정을 추가해야 한다.

다시 제어판에 가서 사용자 메뉴를 선택한다.

사용자 메뉴에서 [생성] 버튼을 클릭한다.

사용자 정보를 입력한다.

사용자 계정을 gituser라고 했다.

gituser의 그룹은 users로 선택한다.

gituser는 homes만 접근권한을 줬다.

그 이후는 모두 다음 .. 다음 넘어가면 되고 혹시나 싶어서 WebDav는 허용하였다. 

4.Repository 생성

NAS에서의 작업은 끝이 난거 같다.

Windows 를 사용하는 관계로 PuTTY를 이용해서 Repository를 생성해야 되겠다.

PuTTY를 실행하고 root로 로그인을 한다.

키보드를 두드릴 시간이 왔다.

NAS에 disk가 하나가 있어 그 놈은 volume1인데 그 놈의 이름이 /var/services 이라는것 같다.(리눅스를 잘 모름)

아뭏튼 gituser라고 만든 계정의 홈은 /var/services/homes/gituser가 된다.

여기에 project.git 이라는 폴더를 생성고

그 폴더로 들어가서 Repository 초기화(?)라나 뭐 그렇게 해준다.

그리고 cd .. 하여 상위 폴더로 올라와서

project.git 이란 폴더의 하위 전체의 권한을 gituser에 넘긴다.

chown -R (git사용자 계정):(git 사용자가 속한 그룹)  (사용자 디렉토리)

여기까지 하면 Git Server의 설정이 끝이다.

5.Windows 에서의 설정

이것도 참 고생을 했다.

개념 모르고 덤비니 가시밭길이 이만 저만이 아니다.

그래도 다 왔다.

참고로 Windows에서의 Git 에 대한 사용법은 http://backlogtool.com/git-guide/kr/ 여기를 참고했다.

TortoiseGit 프로그램을 설치를 한다.

그리고 나서 Windows 원하는 경로에 repository를 생성한다.

그리고는 다시 TortoiseGit의 Settings 화면에서 사용자를 저장한다.

이 때 사용자는 NAS에 만든 gituser가 아닌 개발자를 의미한다.(개발자마다의 개별 설정)

제일 중요한 마지막 설정이다.

URL 은 http로는 성공을 못했다. 그래서 ssh로 했다.

ssh://(NAS에 생성했던 계정)@(NAS의 DNS):(포워딩한 port)/volume1/homes/(사용자 계정 폴더)/(Repository 폴더 명)

(예 ssh://gituser@nas.familyds.com:9112/volume1/homes/gituser/project.git)

- ssh의 표준 포트는 SSH 서비스 활성화에서처럼 22이다.

  세상이 무서워서 port forwading을 하는게 좋을꺼 같다. 임의의 숫자로

- /volume1 대신 /var/services 라고 써도 되는거 같은데 다음에 설정할 일이 있으면 그렇게 해 보아야겠다.

이렇게 해서 NAS에서의 Git 사용에 관련된 모든 설정을 완료한거 같다.

많은 시간을 들여서 해 놓은 삽질을 잊어버리기 전에 이렇게 정리한 번 해 보았다.

[출처] http://kongzz.tistory.com/14

처음에는 Rebase를 왜 해야 하고 언제 어떻게 해야 하는지 좀 헷갈린다. 헷갈리는 이유는 정답이 없고 미묘함이 있어서인데 그래도 대략적인 가이드가 있으면 좋겠다 싶어서 정리해보았다.

Social Coding Platform

svn이나 다른 VCS 도구 말고 git을 사용해야 하는 이유는 커뮤니케이션이다. 개발이라는 작업은 혼자 하는 게 아니라서 코드를 공유하고, 리뷰하고, 피드백을 받아야 하는데 Git으로 하면 일이 좀 쉬워진다(Git이 쉽다는 것은 아니다).

git과 github의 인기는 VCS 본연의 기능뿐만 아니라 커뮤니케이션을 원활하게 할 수 있는 플랫폼이 함께 필요하다는 것을 보여준다. git은 소스관리에도 뛰어난 도구지만 그게 Git만의 장점은 아니다.

git은 단순히 VCS가 아니다. 소스관리뿐만 아니라 커뮤니케이션에 필요한 모든 것이 들어 있다. 특히 코드를 공유하는 것은 정말 끝내 준다. Git 이외에 필요한 도구가 별로 없다. 나는 히스토리를 엉망으로 관리하는 프로젝트을 살펴보고자 gitx를 가끔 사용하고 차이를 살펴보고자 diffmerge를 아주 가끔 사용한다. 정말 아주 가끔이다. 한 달에 한 번도 실행하지 않는다.

그 외에는 항상 콘솔에서 작업한다. git은 아직도 발전 중이고 코드를 쉽게 공유하는 방법이 계속 통합될 것으로 생각한다. git에는 정말 필요한 모든 것이 통합되고 있어서 언젠가 git으로 문자 메시지로 코드를 보낼 수 있는 날이 올지도 모른다는 상상을 하고 있다.

배려

동료는 그녀와 같다. 배려 없이 초대에 응하는 그녀는 없다. 최대한 친절을 베풀어야 그녀를 내 저장소로 초대할 수 있다. 공포를 조장하거나 무턱대고 돈만 살포해서는 진심을 이끌어 낼 수 없다. 스스로 응할 때까지 배려하고 인내해야 한다.

코드는 당연히 잘 짜야 한다. 버그는 없을수록 좋고, 주석은 간략하고 명확해야 하고, 변수나 함수이름, 파일이나 디렉토리 구조나 이름 등등…. 중요하지 않은 것이 없다. 좋은 글에는 좋은 문장도 많은 법이다.

git도 마찬가지다. 변수 이름을 잘 짓듯이 브랜치 이름도 잘 지어야 한다. 커밋 메시지도 표준 포멧에 따라 잘 지어야 한다. 그리고 히스토리도 예쁘게 만들어야 한다.

Merge vs Rebase

Rebase는 히스토리를 단장하는 데 필요하다. 나 혼자 쓰는 저장소에서도 Rebase가 없으면 지저분해서 히스토리를 읽을 수가 없다.

잘 정리한 히스토리를 엿보고 싶다면 npm 저장소를 구경해보는 것이 좋다. @izs님은 완전 git타쿠:

히스토리가 정말 보기 좋다. github의 'pull request'도 사용하지 않고 죄다 손으로 Merge하는 것 같다.

커밋 vs Merge 커밋

Merge와 Rebase를 살펴보기 전에 커밋부터 다시 살펴보자.

커밋은 의미의 단위다. 지금 하는 일을 적당하게 한 조각으로 나눠서 커밋한다. 10줄, 100줄처럼 정량적인 단위가 아니다. 고기를 사듯이 '커밋 한 근 주세요.'라고 말할 수 없다. 커밋 하나는 의미 하나다.

커밋 하나하나에도 의미가 있지만 어떤 모듈을 개발한다면 여러 개를 하나로 묶어서 처리할 필요도 있다. 그러니까 여러 개의 커밋을 묶음으로 표현할 수 있는 커밋이 필요하다. 그게 Merge 커밋이다. Merge 커밋은 일종의 커밋 묶음이다

npm 저장소에 @izs님이 만들어 놓은 Merge 커밋을 보자:

1ecd0eb는 gyp를 구현한 커밋들을 묶어 놓은 Merge 커밋이다. gyp 브랜치를 만들어 gyp를 구현하고 master 브랜치로 Merge했다.

Merge 커밋은 사실 커밋 묶음 나타내는 것이 아니다. 보통 커밋은 Parent가 하나인데 Merge 커밋은 Parent가 여러 개다. 하지만, Parent가 여러 개인 점을 이용해서 커밋 묶음으로 다룰 수 있다:

C6는 Merge 커밋으로 Parent가 두 개다.

Merge 커밋을 Reset하면 관련 커밋이 전부 Reset된다:

C3와 C5가 같이 Reset되기 때문에 master 입장에서는 커밋 묶음이 Reset된 것이다.

npm 저장소에서 master 브랜치가 Merge 커밋인 1ecd0eb를 가리키는 상태에서 'HEAD~1'으로 Reset하면 gyp 브랜치가 통째로 Reset된다. 그래서 master는 c4eb2fd를 가리킨다.

Merge vs Rebase

다음과 같은 브랜치를 Merge, Rebase해보고 그 결과를 비교해보자:

git merge iss1 명령으로 iss1를 Merge한다. 노란색인 C1은 Merge Base이다:

git merge iss2 명령으로 iss2를 Merge한다:

git merge iss3 명령으로 iss3를 Merge한다:

iss1, iss2, iss3를 Merge 했다. C9, C10, C11은 Merge 커밋이다. 이 그림에서는 히스토리가 복잡하지 않다고 생각할 수 있지만, 이정도 되는 내용도 콘솔에서 보면 헷갈린다. 한눈에 들어오지 않는다. 이제 Rebase 후 Merge해보자.

헷갈릴 수 있으니 원본 브랜치를 다시 한번 보고:

git checkout iss1과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C1이 아니라 C4가 된다:

git checkout master과 git merge iss1를 차례대로 실행해서 Merge한다. Rebase를 하면 항상 Fast-Forward Merge가 가능해진다. 하지만, 무턱대고 Fast-Forward Merge를 하는 것이 아니라 앞서 얘기했듯이 커밋을 묶음으로 관리하고 싶지 않을 때만 Fast-Forward Merge한다. 이 경우는 커밋이 하나이므로 그냥 Fast-Forward Merge한다:

git checkout iss2과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3가 아니라 C2'가 된다:

git checkout master과 git merge --no-ff iss2를 차례대로 실행해서 Merge한다.--no-ff 옵션은 강제로 Merge 커밋을 남기려고 주는 것이다. iss2 브랜치는 커밋이 두 개고 이 커밋은 iss2를 처리한 결과이므로 커밋 묶음으로 처리하는 것이 낫다(물론, 내용상 --no-ff 옵션을 주는 게 틀릴 수도 있다.):

git checkout iss3과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3에서 C9이 된다:

git checkout master과 git merge --no-ff iss3를 차례대로 실행해서 Merge한다:

다음 그림은 위에서 Rebase 없이 Merge한 결과다. 한번 비교해보자:

Rebase를 하고 나서 Merge한 것이 훨씬 보기 좋다. 아무리 복잡한 과정을 거쳤어도 한눈에 들어오게 할 수 있다.

마치며

Git처럼 히스토리를 다중으로 관리하는 시스템에서 Rebase는 필수다. Mercurial도 Git의 영향을 받아 Rebase를 지원한다. 이글에서는 Rebase가 왜 필요하고 언제 어떻게 해야 하는지 알아봤다.

UPDATE: 20121122

Merge Commit은 Commit을 묶음으로 관리하는데도 유용하지만 Release Note에 넣을 만한 것을 미리 Merge Commit으로 만들어 놓으면 편리할 것 같다. 배포할 때 Merge Commit만 추려볼 수 있으니 Release Note를 따로 작성하지 않아도 된다.