git flow command line tool

===

git flow init - develop이라는 브랜치가 만들어짐.

git flow feature start login 하면 feature/login 브랜치가 만들어짐

develop에서 원격으로 연결하기
git remote add origin [주소]
git push --set-upstream origin develop(▽add만 하면 기본 브랜치가 안정해져있으니까 해주는건가?)

지금 로컬에 master, develop, feature/login이 있는데

git flow feature publish login : 
원격 저장소에 feature/login 브랜치를 만들고(github에 만들어진다 신기하네)
로컬 저장소의 feature/login브랜치와 연결한다

git flow feature finish login

(1)로컬의 feature가 develop으로 merge됨

(2)로컬의 feature삭제

(3)원격의 feature삭제

=>원격의 develop으론 push안된다. 내가 해줘야해

 

===

https://youtu.be/w2F8O9J1keM

 

===

이 수업에서는 git 브랜치 모델 중 가장 유명한 git flow에 대한 소개와

이 모델을 쉽게 사용할 수 있게 도와주는 도구인 git flow cli 를 다룹니다.

프로젝트를 체계적으로 관리하는 지혜가 담겨있습니다.

 

===

(브랜치가 없을 때)두개의 기능을 동시에 개발 할 때, A는 곧 끝나고 B는 시간이 좀 더 필요해

 

이 상태에서 출시가 확정됐을 때, 문제는 기능 B이다

행동 가지 수

1.기능 B가 끝날때까지 출시를 연장한다 : 출시일이 미뤄진다

2.기능 A작업이 끝날때까지 기능 B를 미뤄두기 : A와 B를 동시에 작업할 수 없다.

->기능 A만 이번 출시에 포함시키면서 기능B에 대한 작업을 계속하려면 어떻게 해야할까?

 

===

이 상황에서 우릴 구원해주는 도구가 깃의 브랜치다

둘이 분리해서 하나에선 출시 준비 작업을 하고, 개발 브랜치에선 장기적인 작업을 지속해줄 수 있다.

 

그럼 이때 고민이 생김. 어떤 브랜치를 만들고 또 어떻게 운용해야할까?

 

===

이런 문제를 해결하기 위해 존재하는 도구가 브랜치모델

브랜치 모델에서는 브랜치의 이름, 이름에 따른 임무들을 규정해 놨다

가장 유명한 브랜치 모델이 git flow, git flow를 채택하면 브랜치 전략을 짜기 위해 고민 안해도 된다

유명하니까 배울 수 있는 방법도 많고, 이미 알고 있는 사람도 많다

 

하지만 전략을 따르는 것이 쉽진 않다.

정책에 맞게 명령어를 입력해야되는데 그러려면 수련이 필요하다

얘네는 git flow모델을 따르고 있을 때 

출시를 끝마친 직후에 내려야할 명령어들이다 복잡해

 

===

이런 상황에서 우리를 구원해줄 도구가 git에 내장된 도구인 git flow

이 기능을 이용하면 저렇게 복잡한 작업을

한줄의 명령으로 대신할 수 있다

=>git flow모델의 명령을 자동화해주는 도구 git flow command line 프로그램

 

===

git flow cli 프로그램 사용법

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

http://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

 : git flow를 사용하는 방법이 아주 잘 정리돼있는 문서다. 이걸 같이 보면서 진행할 것

 

===

git flow cli를 사용할 땐

제일 먼저 git flow라고 입력

그럼 git안에 내장돼있는 도구가 실행됨. 사용할 수 있는 여러가지 명령들이 나옴

제일 먼저는 init을 먼저 해야해

이미 갖고 있는 저장소에서 ( git init )

git flow init 해도되고

 

그냥 git flow init 해도 저장소가 만들어진다

그럼

이게 뜨는데

각각의 역할에 따라서 브랜치의 이름이 다르다. 그 이름을 뭘로 할건지 물어보는 것

 

productio releases버전이 들어갈 브랜치를 뭘로할건가. 그냥 엔터치면 저 master대로 된다

다음부터 나오는것도 다 엔터치면 대체로 문제없다

이러면 ▽develop이 만들어지고 checkout됨

저 파일안에 git flow관련 설정들이 세팅됨

 

===

여러분들이 상황을 잘 파악할 수 있게 하려고 아래쪽에 log명령으로

1초에 한번 업데이트 하면서 실행을 시켜놓을게요

 

===

시작

git flow의 가장 큰 원칙은 master와 develop브랜치를 구분한다는 것

master브랜치는 언제나 실행가능, release가능할 정도에 제품으로서의 완결성이 있는 손실이 없는 버전이 master에 온다

실제 일상적인 개발은 develop브랜치에서 진행된다

 

init을 하게되면 기본적으로 develop브랜치로 바뀌어있는걸 볼 수 있다

vim dev.txt 작업

git add dev.txt

git commit -m "dev 1"  --버전이 하나 만들어진다

이렇게 일상적인 작업을 하다가 새로운 기능을 개발해야된다 할 떈 feature branches를 시작한다

오른쪽에 명령어의 형식이 나와있지

git flow feature start login 하면 feature/login 브랜치가 만들어짐

그 아래는 어떤 작업을 나 대신 해줬는지 알려줘

feature/login 브랜치를 만들었다 develop을 base로 + checkout

 

 

===

그럼 다음부터 feature 관련 작업들을 해나감

vim login.txt

git add login.txtg

git commit -m "login 1"

이렇게 feature에서 작업들을 계속 해나감

 

동시에 일상적인 작업들은 feature가 아니라 develop에서 진행

git checkout develop

vim dev.txt

git commit -am "dev 2"

 

이렇게 feature / develop 각자 자신의 길을 간다

 

===

원격저장소와 상호작용하는 방법

지금 창 3개다

 

부모디렉토리(cd ..)로 가서 remote라고 하는 원격저장소를 만들게요

git init --bare remote  *bare는 원격저장소를 만들 때 사용하는 옵션

생겼다

cd remote

 

이 원격 저장소로 지금까지 작업했던 것을 옮겨볼것

git remote add origin ../remote

 

여기까지 하고 git push하면 

로컬의 develop과 원격저장소의 develop을 연결을 한번은 해줘야한다(add하고+setupstream해줘야되는구나)

알려주는 명령을 그대로 카피해서 실행

git push --set-upstream origin develop

그럼 푸시가 된다

develop은 이렇게 푸시하고, feature도 똑같이 하면 되는데, git flow가 기능을 제공해준다(▽깃이 브랜치별로 푸시해야된다는 소리)

 

git flow feature publish login이라고 하면

원격 저장소에 feature/login브랜치를 만들고, 

로컬 저장소의 feature/login과 연결시키고, 하는 작업을 해준다

이게

이렇게 바뀜, origin/feature/login으로 잘 푸시가 된 것

 

===

그럼 이제 develop과 feature브랜치를 왔다갔다 하면서 여러가지 작업들을 진행한다

그러다 새로운 제품을 출시할 때

이번에 출시할 제품에 들어갈 기능들과, 버그, 기능개선들을 목록화해서 준비가되면

1.이번에 포함될 feature를 develop으로 병합

git flow feature finish login

브랜치도 자동으로 삭제해줌. 대신 커밋메시지를 통해 그 흔적을 남기게 된다

▽이때 내가 해보니까 pr에서 merge버튼을 누르고 로컬와서 git flow feature finish login해보니까

이게 떠. 원격까지 같이 해주나봐. 그래서 로컬은 내가 merge하고 branch지움

 

2.release절차 시작

git flow release start [릴리즈할 버전]

release/1.0이라는 브랜치가 생기고 checkout까지된다

작업

커밋

*release를 나누는 이유 : 나누지 않으면 일상적인 작업들이 계속해서 들어오게 되면서 그로 인해 release가 지연될 수 있다. release에 필요한 모든 작업들을 release에서만 진행한다.

 

release에서 작업한것들은 어차피 develop에서 필요한 작업이다.

늦게 반영할 수록 충돌 지옥을 맛보니 자주자주 병합하라

 

3.release완료

- 작업한 브랜치를 master브랜치로 병합

- master브랜치에서 어떤 목적의 release였는지 알려주기위해 버전에 대한 태그

- release작업은 언젠간 develop에 필요한 작업이므로 develop으로도 병합

git flow release finish 1.0

처음 나오는 화면은 master와 병합할 커밋메시지 : 그냥 wq

그다음 화면은 어떤 이름의 태그를 쓸건지 : 그냥 1.0

그 다음 화면은 develop으로 병합 : 그냥 wq

release와 병합된 master가 생기고, tag가 붙는다

또 develop과 병합

 

===

hotfixes

긴급하게 버전을 출시해야 되는 경우

 

develop에서 가져오게되면 develop에서 진행되고 있는 일상적인 작업들 때문에 바로 출시하기 어려울 수 있다

이미 출시가 된 버전에서 문제가 된 코드만 딱 hotfixes브랜치에서 작업하고

이 작업이 끝나면 hotfixes에서 작업한것을 마스터로 병합하고 develop으로 병합하는 과정을 할 수 있다

 

git flow hotfix start login

hotfix로그인 브랜치가 생김

작업

커밋

핫픽스 작업 끝나면 git flow hotfix finish login

첫화면은 master와 병합할 커밋메시지

다음화면은 태그

다음화면은 develop과 병합