Git-flow
브랜치를 큰 범주 4개로 나눠 개발하는 전략
Main branch?
master, develop 브랜치를 보통 메인 브랜치로 사용한다.
두 브랜치는 병행으로 유지한다.
master: 배포 가능한 상태
develop: 배포할 것을 개발하는 상태
Feature branch or Topic branch?
보조 브랜치(feature, topic)로 기능을 개발하는 브랜치이다.
develop에서 분기하며 feature -> develop 으로 merge한다.
feature브랜치는 개발자 저장소에만 존재하고 origin에는 push하지 않는다.
Release branch?
develop브랜치에 기능이 merge되면 QA를 위해 develop -> release브랜치 생성
배포 전 최종 버그 수정, 개발 진행
-> 배포 가능 상태
-> master 브랜치 merge (버전 up)
-> release 브랜치에서 기능을 점검해 발견한 버그 수정은 develop에도 적용
-> 배포 완료 후
-> release에서 develop으로도 merge
Hotfix branch?
배포한 상태에서 긴급 수정이 필요할 경우 master에서 분기처리
버그를 수정하는 동안에도 develop에서는 작업을 이어갈 수 있다.
hotfix의 수정사항은 develop에도 merge하여 문제처리를 해야한다.Main, Dev 브랜치가 중심을 이루고 Merge된 feature, release, hotfix 브랜치는 삭제합니다.
주기적인 배포가 이뤄져야 하는 프로젝트에 적합하다.
브랜치가 복잡해지는 상황에서는 프로젝트에 따라서 브랜치의 구분이 명확하지 않을 수 있다.
GitHub-flow
Git-flow가 Github에서 사용하기에 복잡해 나온 전략
master브랜치에 대한 역할만 명확하다면 다른 브랜치는 관여하지 않는다.
hotfix, feature브랜치를 구분하지 않는다. 우선순위에 차이가 있다.
pull request 사용을 권장한다.
해당 전략은 배포가 수시로 발생하며 CI/CD 프로젝트에 유용하다.
Master 브랜치는 항상 배포가 가능하다.
Master브랜치로 merge하기 전에는 충분한 테스트가 이뤄져야하고
테스트는 로컬에서 하지 않고 해당 브랜치를 push하고 CI툴을 사용한다.
새로운 작업은 Master에서 브랜치를 분기하고 이름을 명확히 한다.
(develop, feature 브랜치가 존재하지 않는다.)
Commit Message를 명확히 작성한다.
Remote 브랜치로 push를 수시로 한다.
(소스코드 보존확률이 올라간다)
파드백, 서포트, 완료시에는 pull request 생성
-> 승인
-> Master merge
-> 즉시 배포(CD)
devLog