git - flow 전략

브랜치 전략 중에 git - flow 전략과 github - flow라는 방식이 있는데 

저번주부터 github로 협업을 하면서 막막하기만 했던 github 협업이 어느정도 자리를 잡아가는것 같은

느낌을 받아서 블로그를 적는다.

두가지 모두 확실히 딱 사용했다 나는 이제 잘안다 라고 할 순 없겠지만

어느정도 묘사는 해봤기에 각각의 장단점에 대해서 잘 알 수 있을것만 같다.

 

git - flow 전략

 

총 5가지의 브랜치로 구성되며

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

와 같은 각각의 역할을 가지고 있다.

1. master 

master는 실제 서비스를 하는 브랜치이므로 굉장히 조심스러운 접근이 필요하다.

실제 제품 출시와 연관이 있는 브랜치이기 때문에 모든 테스트들을 완료했을때에만 master로 머지한다.

 

2. develop

나머지 브랜치들이 실질적으로 뽑아져 나오는 공간이라고 볼 수 있다.

master는 실제 서비스와 연관 되어 있기때문에 master에서 브랜치를 따서 작업을 하기에는 리스크가 너무 크기에

develop이라는 브랜치를 새로 만들어서 이 곳에서 새로운 기능 및 버그 fix와 같은 일들을 수행할 수 있도록 

다른 브랜치에게 작업물을 보내주게 된다.

 

3. feature

실질적인 새로운 기능을 개발하는 공간이다. develop에서 브랜치를 새로 만들어서 가져오고

feature에서 기능개발을 완료한 이후 거기서 바로 테스트를 진행한다.

이후 이상없다면 develop에 푸시를 하고 develop에 모인 커밋들을 다시 모아서 테스트를 진행한다

이후 develop에서 문제가 없을시 그대로 master에 푸시하게 되는 순서로 동작한다.

 

그렇다면 머지할때 master로 머지하게 될 경우가 생기게 되는데 현업에서는 이러한 경우를 대비하기 위해

바로 머지가 되지 않고 팀원들 혹은 팀장의 승인이 떨어지는 경우에만 머지를 할 수 있게끔 조치를 해둬서

master로 바로 머지되는 참사를 막게 된다.

 

github - flow 전략

git - flow에 비하면 굉장히 단순한 편인데 github - flow 전략 자체가 git - flow 전략의 복잡한 프로세스를 지적하게되면서

나오게 된 브랜치 전략이다.

워크 플로우를 단순하게 하여서 개발자들이 쉽고 빠르게 습득할 수 있도록 하는데에 의미를 두고 있다.

특징은 master 브랜치를 하나만 두는 방식을 고수하는 것이 특징이다.

master를 제외한 모든 브랜치는 개발자의 재량에 맡기므로 복잡할 필요도 없고 자유도가 높다.

master는 언제든지 배포가 가능하고 모든 배포와 수정 피드백 역시 master에서 진행된다.

하지만 단점으로는 말그대로 master에 바로 머지하기때문에 머지하기전 테스트에 있어서 철저해야하는 단점이 있다.

 

 

이 두가지를 비교한다면 미니 프로젝트와 같은 소규모 프로젝트에는 github - flow가 더 맞는 전략이다.

git - flow처럼 많은 브랜치를 두지 않았기 때문에 혼선을 빚을 일이 적고 바로바로 머지하고

부족하거나 잘못된 부분이 있다면 또 바로 머지를 하면서 수정을 할 수 있다는 장점이 있다.

 

출처 : http://blog.hwahae.co.kr/all/tech/tech-tech/9507/