Git flow에 대해 간단한 정리

 

git flow를 대표하는 그림이다. 

 

기존의 내가 알고 있던 프로젝트 협업 방식은 master 브랜치 하나를 중심으로 개발자마다 브랜치를 하나씩 생성해 개발한 후 

PullRequest 를 신청해 관리자가 확인 후 최종적으로 merge 하는 방식이었다.

하지만 이 방식은 충돌위험성과 유연성?이 떨어진다고 알고 있다...(정확히 설명하지 못하겠네,, 좀 더 공부해야할듯)

git flow 방식은 기존의 방식보다 더 효율적이고 변화에 유연하게 대처할 수 있다.

 

- master branch : 배포되었거나 배포될 소스가 저장된 브랜치

- develop branch : 다음 배포를 위해서 개발을 진행하는 브랜치

- feature branch : 각 개발자들의 기능 개발을 진행하는 브랜치

- hotfixs branch : 배포 버전에 생긴 문제로 긴급한 트러블슈팅이 필요할 때 개발이 진행되는 브랜치

- release branch : 내부적으로 배포할 준비가 되었다고 생각하는 소스가 저장되는 브랜치

 

 

develop branch는 여러 명의 개발자가 함께 공유하면서 진행하는 브랜치이다. 

develop branch를 뼈대로 삼아 기능을 개발할 로컬 브랜치를 만들어 개발을 진행한다. 두 가지 방식이 있을것 같은데,, 두 번째 방식은 확실하진 않고 내 뇌피셜임다.

 

첫번째 방식 -> 기능 개발이 완료되면 develop branch에 push를 한다. push하면 기능 개발한 branch는 삭제시키면 됌(develop branch에 push를 하기 전에 원격 develop branch를 pull 한번 해주자! 다른 개발자들이 push를 해서 원격 develop branch와 일치하지 않을 수도 있기 때문!!) 그 다음 원격 develop branch에 push를 진행하면 된다.

이게 한 사이클이다. 다음 기능 개발건이 생기면 다시 기능 브랜치 만들어서 똑같이 촥촥 진행하면 됌

 

두번째 방식 -> 기능 개발이 완료되면 원격 브랜치로 push를 한다. 그 다음 원격 저장소에서 기능 브랜치 => develop branch로 merge request를 진행

 

 

git flow 실습을 해보면서 알게 된 점은...

 

fetch는 원격 저장소의 변경 내역을 로컬 저장소로 가져오는 것 뿐이고(commit 내용 같은것들) 직접 로컬에 반영하진 않는다.

pull은 fetch + merge 까지 한다고 보면 된다.

 

 

참고 링크 : https://jeong-pro.tistory.com/196

나의 Git Flow 적응기(겉핥기로 10분만에 익히고 써먹어보자, 백각이불여일행!)