GITHUB 협업 2 TIPS - git flow

conflict 문제 해결법, branch 생성법을 배웠으니 

git-flow 즉 현업에서 git 을 어떻게 관리하는가에 대해 알아보자! 

 

참고글 

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

Git flow, GitHub flow, GitLab flow

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

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

 

Git Flow 

Git Flow는 Vincent Driessen 이라는 사람의 블로그를 통해 널리 알려졌고, Git 개발 시 표준과 같은 방법론

(기능이 아닌 서로간의 약속인 방법론)

 

Git Flow 에는 다음의 대표적 브랜치가 있다. 

 

master : 제품으로 출시될 수 있는 브랜치 

develop : 다음 출시 버전을 개발하는 브랜치 

feature : 기능을 개발하는 브랜치 

release : 이번 출시 버전을 준비하는 브랜치 

hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

 

Feature > Develop > Release > Hotfix > Master

Merge 순서는 앞에서 뒤로 진행된다. 

나와 같은 Git 초보자들은 지금 무슨 말을 하는지 전혀 이해가 안 될 것이다. 그림과 자세한 설명으로 살펴보자. 

위 브랜치는 마치 폴더 관리 같다. 

 

2022 년도 1학기 폴더를 관리한다고 하면, 그 안에 각 수업, 그리고 각 수업안에는 프로젝트, 과제 등의 폴더가 존재한다. 

다음의 git flow 를 하나의 수업이라고 생각해보면, 

master 브랜치(2022년도 1학기 폴더)는 최대한 건들일이 없을 것이고 그 안의 수업(develop)에는 각종 수업 관련 폴더(features) 등이 생성 될 것이다. 

 

즉, 큰 흐름에서 보면 master, develop, feature branches 를 이해할 수 있다. 

 

master: 말그래도 최 후방의 브랜치로, 모든 자료가 합쳐지고 정리되어 존재하는 곳이다. 

각 버전 출시직전에만 merge 되는 곳이다. 

 

develop: 개발해야 하는 중요 기능들을 개발하여 합치는 곳이다. 즉, 새로운 기능을 추가하게 되면 feature branch를 새로 하나 파서 개발을 진행한 후, 마무리 되면 develop로 합친다. 

 

feature branch: branch 설명에 포함됨 

 

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보면 된다.

 

hotfix: 이미 배포를 마친 버전에서 긴급한 에러나 수정사항이 발견되었을 때, 빠르게 그 부분만 수정한 후 배포 버전에 반영시키기 위해 존재하는 branch이다. 다만, 수정된 부분은 develop에도 반영되어야 한다. 

 

release: 각 버전을 컨트롤 하는 곳이다. 각 버전이 완료되어도 최종 배포하기전까지는 몇번의 수정 작업을 거치게 된다. 해당 과정이 이루어지는 브랜치이다. 

 

각 부분을 예시로 살펴보자. (해당 예시는 배민 블로그에서 그대로 가져왔음을 밝힙니다.)

 

 

• 일단 master 브랜치에서 시작
• 동일한 브랜치를 develop에도 생성. 개발자들은 이 develop 브랜치에서 개발을 진행.
• 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합
• 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합침.(Merge)
• 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스.
• 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포.
• 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포.

 

추가적으로 알아야 할 사항은 rebase 

rebase 는 복잡해진 commit을 깔끔하게 관리할 때 사용되는데, 이 뿐만 아니라 feature에서 기능