출처 : 코딩애플

1. Why?

협업시 마구잡이로 브랜치를 만들어 쓸 경우 가시성이 떨어지고 꼬일 가능성이 높다.

2-1. How? (GitFlow)

GitFlow 전략은 크게 5개의 브랜치로 나눠서 작업할 수 있다.

• main
• develop (개발용 branch)
• feature (develop에 기능추가 branch)
• release (develop branch를 main branch에 합치기 전에 최종 테스트용)
• hotfix (main branch 버그 해결용)

Step.1

main 브랜치의 사본을 develop브랜치로 만들어 개발은
develop브랜치에서만 할 수 있게 한다. (main 브랜치 날라가면..어휴..)

Step.2

신기능은 feature/뭐뭐~ 로 나눠서 기능개발하고 develop에 합친다.

Step.3

기능들이 완성된것 같으면 main에다 바로 합치기전(상남자면 합쳐도된다고 코딩애플센세님께서 말씀하셨지만..) 유저 테스트를 받거나 여러 버그를 대처한다.
출시 준비 단계 / 완성되면 main에다 merge한다.

Step.4

배포 이후 버그를 발견하였을때, main에서 branch해서 버그 수정 가능

• 수정이 완료되면 main 브랜치에 직접 merge
• 당연히 develop 브랜치에도 merge 필수
  

Fin.

특징
출시된 버전의 안정성이 중요한 프로그램들,
아직 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 git flow가 적절

2-2.How?(Trunk-Based)

Trunk-Based 전략은?
main 브랜치 하나만 운영 하면서 수정이 필요할때마다 브랜치를 메인에서 뽑아다 수정후 main으로 merge 해주는 방식 = github flow랑 유사

• 브랜치 마다 작명을 잘해주는것이 좋다.
• 브랜치의 기능을 main에다 merge 완료하면 브랜치 삭제가능
• main 브랜치의 수정본을 필요할때마다 유저들에게 배포
  
  
  특징
  코드를 한 브랜치에서만 관리하기때문에 편리함
  main 브랜치에서 실수하면 큰일나기 때문에 빡세게 테스트 필요

출처 : 코딩애플