Git Branch Flow

현재 보호받고 있는 브랜치

main

• 출시
• Hotfix

develop

• 지금까지 개발 내역
• 버그 수정
• 현재 진행중인 스프린트에 포함되지 않는 작업을 할 때, develop 브랜치로부터 새로운 브랜치를 생성한다.

release

• 스프린트 작업
• 현재 진행중인 스프린트에 포함되는 작업을 할 때, release 브랜치로부터 새로운 브랜치를 생성한다.

브랜치 원칙

• 스프린트 시작 상태

  develop → release

  → release 브랜치를 하나 더 두는 이유는 release 브랜치엔 스프린트에 해당되는 작업들만 존재할 것이기에 버그나 오류를 파악하기가 쉽기 때문

• 스프린트가 진행되면

  release → releaseLocal (자유)

  releaseLocal → dani/feature1 , …

  → releaseLocal 한번 더 따는 이유는 모두가 초기의 release 브랜치 상태를 유지하기 위함

• develop → develop 으로는 버그 수정 외에는 웬만하면 머지하지 않는다

  → 버전 관리를 위해. 오류의 시작점이 확실치 않으면 문제가 된다

• release → release 로 머지해도 됨

  → 이미 초기 release 상태가 보장되어 있고, 뒤늦게 한꺼번에 merge를 하면 무수한 컨플릭이 날 수 있다

• 협업의 경우

  한 사람이 협업을 위한 브랜치를 생성하고, 그 브랜치를 업스트림으로 설정하여 최신 작업을 받으면서 계속 브랜치를 생성/머지하면서 작업한다. 협업이 완료되면 최초이자 최종 브랜치인 협업 브랜치를 원본 레포지터리로 pr을 날린다. *정말 정말 불확실

  → 다른 브랜치들을 보호하면서 협업을 하기 위해서

• 스프린트에 들어가지 않는 작업

  develop 에서 따서 계속 작업하다가 스프린트 머지될 때마다 pull 받아서 conflict 해결해하고, 스프린트에 해당될 때 해당release 로 PR을 날려야 한다

  브랜치는 오래 놔두지 않는 게 좋다.

  → 코드가 업데이트 될 때 마다 계속 pull을 해서 conflict를 해결하는 게 쉽지 않기 때문

  이 문제를 해결하기 위해 스프린트에 들어갈 정도로 태스크를 쪼개는 것을 추천

Git Branch Name

닉네임/작업이름
- Feature 브랜치는 작업이름을 Task명으로 하거나, 작업이름을 정하여 명명
- Feature 브랜치가 아니라도 작업이름
ex. Rey/GitAction, Rey/StudioViewImageResizing