GitBranch 전략 종류
깃 브랜치 전략에는
- Git-Flow
- Github-Flow
- GitLab-Flow
- Trunk-Based Development
- FeatureBranchWorkflow
- 등등 있다.
개인적인 의견
- 깃플로우를 찬양하는 경우들이 많은데 소규모 프로젝트 토이 프로젝트 같은 경우나 깃 전략을 처음 써보는 입장에서는 깃플로우는 과분할 뿐더러 오히력 독약이 된다고 생각한다. 차라리 학습하는 입장이나 소규모 프로젝트의 경우는 더욱 직관적이고 하기 쉬운 깃허브 플로우가 오히려 더욱 유리한것 같다.
- Git-Flow
- -우리 동아리에서 주로 사용하는 전략이다. 처음엔 이 전략의 장단점을 잘 이해하지 못하고 사용하였다
- 알고 난이후 이 전략을 동아리에서 사용해야할 이유를 모르겠다.
- 왜냐하면 우리들이 쓰기에는 쓸데없이 복잡하고 사용하지 않는것들도 있다.
- 대신 회사에서 많이 사용한다고들 하니 연습 목적에 있어서 사용하는것 같다. 동아리에서는 블로그와 같은 대규모 프로젝트에서 사용하거나 클라이언트들이 사용하면 좋을것 같다.
- 오로지 웹만 만들때는 필요없고 모바일앱 같이 버전별 관리가 필요한 곳에서 쓰면 좋을것 같다
- GitHub-Flow
- 다른 전략들에비해 매우 간단하다.
- 와플이나 일회성 프로젝트에 사용하면 좋을것같다.
- 깃을 처음 사용하는 사람들한테 입문용으로 사용하면 좋을것같다
- 동아리에서 적극 활용했으면 좋겠다.
- GitLab-Flow
- 하위로 다양한 전략들이 있어 완벽하게 이해하지 못하였다
- GitFlow를 이해하였다면 이 전략을 쓰는 이점을 크게 모르겠다.
- 과연 이것이 좀더 간단한 것인가?
- 이해중..
- 그냥 규칙만 명확히 한다면 크나큰 차이는 없는것 같다.
GIt-Flow
- 대표적인 워크플로우이다.
- 우아한 형제의 블로그에서는 GitHub-Flow를 사용하다 Git-Flow로 변경하였다고 한다.
- master - develop - feature - hotfix - release 브랜치로 구별하여 사용한다.
- Git-Flow를 사용해서 개발하는 순서는 보통 아래와 같이 이루어진다.
- 처음에 Master(Main)와 Develop 생성
- 새로운 추가 작업은 Develop에서 Feature Branch 생성
- Feature는 Develop으로 Merge(이때 Develop이 최신 상태인지 확인해야함)
- QA를 위해서 Develop에서 Release Branch 생성
- QA에서 발생한 버그는 Release에서 수정
- QA가 끝나면 Release에서 Develop / Master(Main)으로 각각 Merge
- Hotfix는 Master에서 시작하여 수정 후 Master / Develop에 Merge
- 장점 :
- 정기적인 배포가 필요한 어플리케이션
- 버전관리가 필요한 어플리케이션
- 단점 :
- 웹 애플리케이션은 보통 롤백을 하지 않으므로 다양한 버전을 지원할 필요가 없다.]
- 안쓰는 브랜치가 생길수 있다.
master
- master : 브랜치는 배포시에 사용하는 브랜치
develop
- develop : 개발하는 동안 사용하는 브랜치
feature
- feature : 은 기능단위로 만들것을 구별하여 사용하는 브랜치
release
- release : 는 이번 버전에서만 사용할 브랜치
hotfix
- hotfix : 배포버전에서 긴급하게 수정해야할 것이 있을경우 사용하는 브랜치
Github-Flow
- 상시 배포가 필요한 경우 사용
- 단순한 만큼 엄격한 role이 필요하다.
- hotfix와 feature 을 구별하지 않는다 대신에 PR을 사용하도록 권장한다.
사용법
- master 브랜치는 언제든지 배포가 가능하게 한다.
- master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
- 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
- merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 CI 테스트 한다.
- master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성하자
- 브랜치는 항상 master 브랜치에서 만든다
- Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
- 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
- 커밋메시지를 명확하게 작성하자
- 원격지 브랜치로 수시로 push 하자
- Git-flow와 상반되는 방식
- 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
- 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다
- 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다
- pull request는 코드 리뷰를 도와주는 시스템
- 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
- merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자
- 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다
- 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
- 물론 CI도 통과해야한다!
- master로 merge되고 push 되었을 때는, 즉시 배포되어야한다
- GitHub-flow의 핵심
- master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다
GitLab-Flow
- Github flow는 너무 간단해서 배포, 릴리즈 등의 조금 복잡한 이슈를 보완하기 위해 나온 전략이다.
- gitflow는 너무 복잡하고 githubflow는 너무 단순하다 하여 나온 전략으로 서비스가 좀더 커진 경우 사용하면 좋다.
- 아래와 같은 방식으로 사용
- feature
- 모든 기능 구현은 feature 브랜치에서 시작한다.
- feature 브랜치는 master 브랜치에서 분기되고 머지된다.
- master
- gitlab flow의 master 브랜치 역할은 git flow의 develop 브랜치와 같다.
- master 브랜치는 feature 브랜치에서 병합된 기능에 대해 test를 진행
- 전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면 production 브랜치로 머지 만약 staging 단계를 원한다면 pre-production 브랜치로 머지를 진행
- production
- gitlab flow의 production 브랜치 역할은 git flow의 master 브랜치와 동일
- 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치이다.
- pre-production master → production 브랜치 사이에 pre-production 브랜치를 두어 변경 사항을 바로 production에 배포하지 않고 test server에 배포하여 통합 테스트를 진행하거나 시간을 두고 반영하는 브랜치이다.
이외의 파생된 전략
- Merge/pull requests with GitLab flow
- Issues with GitLab flow
참고
Git-Flow https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html Github-Flow https://gist.github.com/ljlm0402/5f69a1e831d8a50bb1b9f4f1fba71f7f GitLab-Flow https://youngtoad.tistory.com/46
'Study > Git 스터디' 카테고리의 다른 글
| GitHub에 작업한 파일 업로드 하는 법 (0) | 2024.01.31 |
|---|---|
| 프로젝트 참여를 위한 기본적인 git & gitHub 사용법 (0) | 2024.01.27 |
| Git 기초 정리 (1) | 2024.01.26 |
| Git 스터디(1 Team)_Git 이론 - 2 (0) | 2024.01.07 |
