Git Branch 전략

1. Git Flow

git flow는 5가지 master(main), develop, feature, release, hotfix branch를 갖는다.

• master(main): 기준이 되는 branch, 제품을 배포하는 branch이다.
• develop: 개발 branch, 이 branch에 각자 작업한 기능들을 merge한다.
• feature: 단위 기능 개발 branch, develop branch에서 feature-* branch를 분기한다. 기능 개발이 완료되면 develop branch에 merge한다.
• release: 배포 전 QA(품질검사)를 위한 branch, develop branch에서 release-* branch가 분기되고 QA 통과 후 develop, master(main)에 merge한다.
• hotfix: 배포된 소스에서 버그가 발생하면 생성되는 branch, hofix branch는 master(main) branch에서 분기되며 수정이 완료되면 develop branch와 release branch에도 수정사항을 반영한다.

이미지출처: https://techblog.woowahan.com/2553/

Git flow 전략은 브랜치마다 상황이 명확하게 분류되어 있지만 이렇게 많은 branch가 흐름을 더욱 복잡하게 하기도 한다.
또한 release branch와 master(main) 브랜치 구분이 모호하다.
하지만 프로젝트 규모가 커질수록 소스코드를 관리하기에 용이하다.

참고: https://techblog.woowahan.com/2553/ 와 https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

2. Github Flow

Github Flow는 복잡한 Git Flow 브랜치 전략을 대신하기 위해 생겨난 브랜치 전략이다.
Github Flow는 master(main) 브랜치 하나로만 진행하는 방식이다.
수시로 배포가 일어나며 CI/CD를 통한 배포자동화가 젹용된 프로젝트에서 유용하다. - ex) Jenkins tool 사용

브랜치 전략이 단순해 master(main) 브랜치에서 pull, 기능 구현, merge의 반복이다.
하지만 pull request에서 팀원간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 자체에서 버그가 발생할 수 있으므로 주의해야 한다.

Github Flow 과정
1. master(main) 브랜치에서 개발이 시작된다.
2. 기능 구현이나 버그가 발생하면 issue를 작성한다.
3. 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature-{구현기능} 브랜치에서 개발을 하고 commit log를 작성한다.
4. push를 하면 pull request를 날릴 수 있다.
5. pull request를 통해 팀원들 간의 피드백, 버그 찾는 과정이 진행된다(단, release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 한다.)
6. 모든 리뷰가 이루어지면, merge하기 전에 배포를 통해 최종 테스트를 진행한다.
7. 테스트까지 진행되면 master(main) 브랜치에 merge한다.

이미지출처 및 참고: https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

3. GitLab Flow

GitLab Flow는 복잡한 Git Flow와 간단한 Github Flow의 절충안으로 볼 수 있다.
master(main), feature, production 브랜치가 존재한다.

• master(main): GitLab Flow에서 master(main) 브랜치는 Git Flow의 develop 브랜치와 같다.
  master(main) 브랜치는 feature 브랜치에서 병합된 기능에 대해 test한다.
  이후 테스트에 통과한다면 production 브랜치에 merge한다.
  
• feature: master(main)브랜치에서 분기되며 모든 기능 구현은 feature 브랜치에서 진행된다.
  기능 구현이 완료되면 merge request를 보낸다.
  merge request에서 팀원 간의 협의가 완료되면 master(main) 브랜치로 merge한다.
  
• production: 배포를 위한 브랜치이다. Git Flow의 master(main) 브랜치와 같다.
  안정된 소스코드가 되었을 때, production 브랜치에 병합해 배포하도록 한다.
  cf) 여기서 견고한 test를 거치고 싶은 경우, pre-production 브랜치를 생성해 production에 병합하기 전에 test server에 배포해 확인할 수도 있다.

이미지출처 및 참고: https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

또는

이미지출처 및 참고: https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5

4. Fork와 Pull Request

규모가 있는 개발의 경우 브랜치 보다는 Fork와 Pull requests(PR)를 활용하여 구현한다.
Fork는 프로젝트를 통째로 복제해서 개발을 하는 방식이다.
Pull requests(PR)로 원 프로젝트 관리자에서 merge 요청을 보내면 원 프로젝트 관리자가 Pull requests(PR)된 코드를 보고 적절하다고 판단하면 그때 기능을 붙히는 식으로 개발을 진행한다.

이미지출처 및 참고: https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5