[Git] Git-Flow

Index

1. Git Flow

2. GitLab Flow

3. GitHub Flow

4. 참고자료

---

1. Git Flow

Concept

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

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

- branch를 merge할 때 항상 -no-ff 옵션을 붙여 branch에 대한 기록이 사라지는 것을 방지하는 것을 원칙으로 한다.

 

gitflow 과정

• master 브랜치에서 develop 브랜치를 분기합니다.
• 개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
• 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기합니다.
• 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
• 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
• 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.

 

 

2.  GitLab Flow

GitLab-Flow

- Gitlab에는 Production 브랜치가 있는데, 이는 Gitflow의 Master브랜치 역

- Gitlab flow의 Master브랜치는 Production 브랜치로 병합
- production 브랜치는 오직 배포만 담당

- pre-production 브랜치는 production 브랜치로 결과를 넘기기 전에 테스트를 수행하는 브랜치

- Production브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신버전 상태를 유지해야할 필요가 없다는 장점

- 복잡한 Gitflow와 너무 간단한 Github의 절충안

• master: production 브랜치
• production: master 이상 권한만 push 가능
• developer 권한 사용자는 master 브랜치에서 신규 브랜치를 추가
• 신규 브랜치에서 소스를 commit 하고 push
• merge request를 생성하여 master 브랜치로 merge 요청
• master 권한 사용자는 developer 사용자와 함께 리뷰 진행 후 master 브랜치로 merge
• 테스트가 필요하다면 master에서 procution 브랜치로 merge하기 전에 pre-production 브랜치에서 테스트

 

 

3.  GitHub Flow

GitHub Flow

- 자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳은 수동으로 진행 

- 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장

- 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용

 

github flow 규칙

- master 브랜치는 어떤 때든 배포가 가능

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
• 이 브랜치에 대해서는 엄격한 role과 함께 사용
• merge하기 전에 충분히 테스트. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트

- master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성하자

• 브랜치는 항상 master 브랜치에서 생성
• 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성

- 원격지 브랜치로 수시로 push 하자

• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 함

- 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성

• pull request를 이용해 자신의 코드를 공유, 리뷰
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구

- 기능에 대한 리뷰와 논의가 끝난 후 master로 merge

• 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영, CI도 통과

- master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

• master로 merge가 일어나면 자동으로 배포가 되도록 설정

 

---

참고 자료

[Blog: Inpa(Git Flow)] https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

[Blog: KWANWOO(Git branch 전략)] https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5

[Blog: 우리는 Github를 이렇게 사용한다] https://medium.com/returnvalues/%EC%9A%B0%EB%A6%AC%EB%8A%94-github%EB%A5%BC-%EC%9D%B4%EB%A0%87%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%9C%EB%8B%A4-83789075e5b6