GIT 브랜치 전략

git 브랜치 전략이란?

브랜치 전략 이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 메커니즘 입니다.

브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 합니다.

즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법 을 말합니다.

널리 사용되는 브랜치 전략은
1. Git-flow
2. Github-flow
두가지로 사용되고있습니다.

멘토링때 배운 브랜치전략은 Git-flow 방식으로
메인 브랜치인 master 와 develop 이 있고, 보조 브랜치인 feature, release, hotfix 로, 총 5가지로 나뉘어 개발이 됩니다.

하지만 저희가 이번 프로젝트에는 gitgub중심 브랜치로 개발이 되기때문에 github-flow 브랜치전략을 응용할것같습니다.

간단히 설명 후 사용 방법을 알려드리겠습니다.
블로그를 보시고 개발에 참고하시면 될 것 같습니다.

Github-flow 브랜치 전략

먼저 github-flow 는 저희가 원래 쓰던 방식과 거의 유사합니다.

github-flow는 master와 develop으로 간단하게 두가지 브랜치구성으로 나뉘어져있습니다.

Github-flow 흐름

1. 브랜치 생성

master 브랜치에 본인의 기능개발을 위한 브랜치를 생성합니다.

이때, 원래 쓰던 방식과 다르게 생성하는데 각자이름의 브랜치에서 개발이 아닌
기능마다 브랜치를 만들어 PR 하는 방식입니다.

그래서 브랜치에 이름을 통해 기능의 의도를 명확하게 나타내주는것이 매우 중요합니다.
ex) boardUpdate, userList ...

이후에는 진행 방식이 비슷합니다.

2. commit, push

개발 진행하면서 수시로 커밋 남깁니다.

커밋 메세지에 대한 자세한 방법은 프로젝트 디스코드를 참고하여 상세하게 적어주는 편이 좋습니다.

3. PR(Pull Request)

이후에 개발이 완료되면 PR을 생성합니다.

4. 코드 리뷰 & 테스트

마지막으로 QA 담당이 merge 하기 이전에 팀원들과 코드리뷰를 하고,
동작 할 때에 발생 할 문제들과 실제로 발생하지 않는지 테스트 코드와 페이지 테스트를 합니다.

별 이상이 없을 시 QA담당이 merge 승인을 합니다.

이후에 배포를 하게 된다면 master에 push 후, 즉시배포까지 되어야합니다.