git flow model

===

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

http://youtube.com/watch?v=EzcF6RX8RrQ&feature=youtu.be 

===

git flow의 간략한 특징은 이렇습니다.

브랜치를 master, develop, feature, release, hotfixes로 구분해서 저장소를 운영합니다.

master에는 완성된 버전만이 속해야 합니다. 언제나 실행 가능해야 합니다.

실제 개발은 develop에서 진행합니다.

신규 기능은 'feature/기능명'으로 구분해서 쉽게 버릴 수 있도록 하고 있습니다.

출시 준비는 'release/버전명'에서 진행하고 준비가 끝나면 master로 병합합니다.

긴급 수정사항은 'hotfixes/차기버전명'을 이용합니다.

이 수업은 git flow model을 쉽게 운영할 수 있도록 돕는 git flow 앱의 사용법을 알려드리는 수업이 아닙니다.

git의 기본명령을 이용해서 git flow 스타일로 브랜치를 운영하는 방법을 알려드리겠습니다.

 

===

git flow는 브랜치를 어떻게 운영할 것인가에 대한 사례중에 하나

또는 이 사례를 잘 쓸수 있도록 도와주는 프로그램을 뜻하기도 함

 

===

master / develop

feature branches / release branches

hotfixes

 

===

git init  --저장소 초기화

main.txt에 내용 적기

커밋

(출시할 때는 그 출시 버전을 어딘가에 기록해놔야 한다)

git tag 0.1 : 이 커밋에 0.1이라는 태그를 붙인 것. 

여기까지 해서 프로그램을 출시했다

 

===

기능개선, 기능추가, 버그수정

이런작업은 master에서 하지 않는다

master의 가장 최신버전은 언제나 실행가능한 상태여야한다.

 

실행가능한 상태를 만들어가는 과정은 develop브랜치에서 진행한다

 

===

git checkout -b develop  --여기서 버그개선 등을 한다

커밋

커밋  --작업을 진행해나간다

 

===

기능개선이 끝나면 출시 준비를 해야겠죠

그때 사용하는 브랜치가 release branches

 

git checkout -b release/0.2  --0.2버전을 출시할 준비를 하겠다

출시하려고 보니까 빨리 수정해야할 버그들이 있는것 그럼 여기서 버그픽스를 하는 것

커밋

커밋

release브랜치에 버전이 만들어지는데 

얘네들은 언젠가 develop 브랜치에 병합돼야 할 애들이다. 그래서

그림에서도 초록색이 노란색으로 계속해서 병합작업을 해줘서 develop브랜치에서 나중에 충돌이 나는것을 최소화시킨다 를 보여줌

git checkout develop

git merge release/0.2

하면

왼before / 오after

▽결국 develop으로 모이지만, develop에 기능이 있고 release에 출시준비는 기능이랑 다른거니까(아마 새로운 기능을 추가했으니 그것에 대한 출시준비?) 브렌치를 따로판다 이거같네.

 

===

release에서 작업하고

develop으로 병합하고 이걸 반복하면서

release준비가 다 끝나면 

 

[release브랜치]를 마스터브랜치랑 병합한다. ▽어차피 develop이랑 release내용 똑같으니까?

이때 일반적인 병합을 사용하지 않고, merge commit을 남기는 형식의 병합을 사용한다

git checkout master

git merge release/0.2  --이렇게 하면 fast forward하기 때문에, 병합이 어떻게 이뤄져 있는지에 대한 기록이 안남아

이래서 git flow모델의 정책은

git merge --no-ff release/0.2

를 쓴다. 커밋 메시지를 의도적으로 만든다. release와 병합했다라는걸 커밋 로그 상에 남길거야!

git merge --no-ff release/0.2이대로 치면

이렇게 커밋 메시지가 만들어지고, 

이렇게 바뀐다.

master가 release를 따라왔어. 그냥 따라오는게 아니라 merge commit을 의도적으로 만들어줬다. 이유는? 브랜치가 너무 많아지는 것을 방지하는 측면. 이때

git branch -d release/0.2  --로 삭제를 해도, merge commit을 통해서 이렇게 병합된 것이다 라는 기록이 남게됨

그리고 버전 기록하기

git tag 0.2

태그가 박혀 있으니까 우리가 언제라도 0.2의 상태로 돌릴 수 있다.

 

===

여기서 또 개발 시작

git checkout develop

신규 기능 두개를 추가할건데, 하나는 금방 끝나고, 하나는 오랫동안 지속돼야 한다고 하면 오랫동안 지속되는것 때문에 release가 미뤄지면 안되겠죠

그래서 금방 끝나는 작업(for next release 분홍) / 그리고 이미 알려져 있는 기존의 작업중에서 버그들(노랑)을 수정하고 그 작업이 끝나면 1.0이라고 하는 정식 버전을 출시하겠다

라고 한다면

이런 모습으로 운영하면 된다라고 하는 그림입니다.

신규기능을 위한 브랜치를 만들고, (for next release 분홍)

버그 픽스들을 하고(노랑)

얘네들을 충족하면 그때 1.0release를 시작한다.

 

===

신규기능을 추가해보자

하나는 금방 끝나고, 하나는 길어

develop으로 복귀하고

git branch feature/short

git branch feature/long

*feature : 기능

git checkout feature/short

여기서 프로젝트를 해나간다

커밋

커밋

git checkout feature/long  --long프로젝트도 동시에 병렬로 진행한다

커밋

커밋

 

===

기존에 있었던 문제와(노랑)

신규로 만들고 있는 기능에 대한 작업이 끝나면

출시 준비를 또 한다

git checkout develop

git merge --no-ff feature/short  --커밋 메시지를 일부러 만들어준다

git branch -d feature/short  --그리고 병합을 했으니 기존 브랜치를 삭제한다.

 

===

release절차를 시작한다

git branch checkout -b release/1.0

그리고 release하는 과정에서 생기는 자잘한 문제들,

short이라는 기능이나 기존에서 문제. 이때는

feature를 새로 만드는게 아니라 여기서 커밋하면서 해결함

커밋들을 해나가면서 release준비를 마친다

develop으로 자주자주 merge를 해주면서 모두 마쳤다면 develop으로 병합 + master로도 병합

git checkout develop

git merge --no--ff release/1.0

git checkout mastger

git emrge --no--ff release/1.0

git tag 1.0

출시 작업 시작

그럼 이제 더이상 release/1.0브랜치는 필요하지 않기 때문에

git branch -d release/1.0

 

===

근데 이 과정에서 갑자기 긴급하게 수정해야하는 심각한 문제가 발견

기능을 추가하고 있는데 빨리 수정하기가 쉽지가 않아

그런 경우엔 기존에 정식으로 출시한 버전의 버전 하나만 추가해서 바로 다음 버전으로 출시해야 하는 경우가 있다

이렇게

이때는 release가 아니라 hotfixes라는걸 쓴다

 

===

git checkout -b hotfixes/1.1  브랜치를 만들고

커밋

이러고 master로 보내고, 당연히 develop으로도 보내서 충돌이 일어나지 않게 하기

git checkout develop

git merge --no--ff hotfixes/1.1

git checkout master

git merge --no--ff hotfixes/1.1

git tag 1.1

git branch -d hotfixes/1.1

 

===

좀 할게 많아서 SW의 도움을 받으면 편하다 : 이름이 git flow야

 

 

===

여기가면 이사람이 만든거야 여기 깊은 설명이 있다