39. gitflow, workflow

 

아마 내가 처음 포스팅한 글이 git과 github에대한 글이였을 것이다. 그때 그 글을 작성했을때만 하더라도 정말 git에 대해서 기초도 잘 몰랐던 시절이였는데 근 한두달사이에 많은걸 배우고 git도 꽤나 친숙해졌다. 이제는 그 git을 이용해서 실제 현업에서 협업하는 방식, 프로젝트를 진행하는 방식등을 배워보고 적용할 시기가 온 것 같다. 많이 친해진 것 같지만 여전히 어색한 git으로 어떻게 해야 효율적이고 트러블없이 협업할 수 있을까?

---

Gitflow

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

우아한 형제들 기술블로그에서 나동호님이 작성하신 git-flow에 대한 설명중 이를 가장 이해하기 쉽고 직관적인 그림이 있어서 가져와보았다. Git-flow를 사용했을 때 작업을 어떻게 하는지 살펴보기 전에 먼저 Git-flow에 대해서 간단히 살펴보자. 우선 Git-flow에는 5가지 종류의 브랜치가 존재한다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.

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

기존에는 master 브랜치에서 혼자서만 작업해왔다. 위의 그림에서 동그라미 하나가 commit이라고 생각하면 된다. 이제 master 브랜치는 건드리지말고 우리의 개발은 develop라는 브랜치에서 진행하자는 것이 gitflow의 핵심이다. 이 때 각각의 브랜치에서 작성한 파일을 commit 하지않으면 다른 브랜치로 넘어가도 따라오게 된다. 따라서 개발은 develop에서만 진행하고 최종적으로 master 브랜치만 배포하도록 한다. 이 때 최종적으로 master에서 합치는 과정을 merge라고 한다.

그럼 develop 브랜치를 살펴보자. develop는 혼자서 개발하는게 아니기 때문에 또 여러 개발자들이 각각의 브랜치를 다시 만들어서 그곳에서 기능을 개발하고 develop 브랜치에서 기능이 다 만들어지면 merge하도록 한다. 또한 develop에서 하나의 기능이 완료되면 바로 master 브랜치에서 merge 하지않고 release braches에서 합치고 이곳에서는 기능개발을 하지 않고 오직 오류만 수정한다. 이곳에서 최종적으로 오류도 모두 수정하고 나면 마지막으로 최종적으로 master 브랜치로 merge 하고 배포한다. 

이렇게 만든 기능이 문제없이 동작했는데 실 서비스를 배포 운영하다가 오류가 발생하면 어떻게 할까? 이럴때는 임시수정용 branch인 hotfix 브랜치로 해당 master 브랜치를 가져와서 이곳에서 수정한다. 이곳에서 수정하다가 기능을 더 보완할 때에는 다시 develop 브랜치로 옮겨서 개발할 수도 있고 마찬가지의 방식의 거쳐서 재배포 하도록 한다.

git branch : branch들 보여줘!
git checkout -b develop : develop 라는 브랜치를 만들고 거기로 이동해줘!
git checkout master : master 브랜치로 이동해줘!
git merge develop : develop에 있는 파일들을 master 브랜치에 합쳐줘!

 

Workflow

Git Fork workflow

메인 저장소를 개발자들이 fork 하고 본인의 레파지토리에서 개발한뒤 main brach에서 merge 하며 협업하는 방식을 Forking Repository 방식 workflow 라고 한다. 이는 아래와 같은 과정으로 협업한다.