git flow 도입기

서론

프로젝트에서 단독으로 프론트 개발을 맡아,
자유롭지만 경험이 많지 않은 신입의 입장에서는 고민되는점들이 하나 둘이 아니라 차근차근 하나씩 나만의 규칙을 정해보기로 한다.
스스로 규칙을 처음부터 정하기보다는 이미 완성된 규칙들을 참고하고,
내 상황에 맞춰 바꿔볼 생각이다

branch

- 브랜치를 나누기

일단 프로젝트를 0부터 시작하는게 아니라, 초기셋팅과 3,4개의 페이지가 작업되어있다.

브랜치는 main하나이며, 기능별로 커밋이 되어있다.

혼자 개발하면 그냥 브랜치 하나로 편하게 하면 되지 않나?

일단 내 답변은 x이다.
브랜치를 나눠 개인별로 할당된 작업, 페이지를 feature브랜치로 나누어 완성한뒤 merge하여 개발을 효율적이게 할 수 있다.

굳이 혼자인데 그럴필요까지야?

여기서 말하는 효율적인 개발의 가장 큰 장점은 개인별로 할당된 작업을 구조화하여 작업하기 위함도 있지만, 개인이 작업함에 있어도 페이지별로 브랜치를 구분하고,
dev브랜치에 merge하기 전에 스스로 코드리뷰와 다른 조언을 받을 수 있는 동료 개발자분에게 코드리뷰를 통해 merge하는 방식.

말이 너무 길어 쉬어가는 줄

사실 아무생각 없이 한개의 브랜치로 개발을 하다보면 혼자 토이프로젝트를 하는 것과 다를바 없다고 생각하기때문에 이렇게 git flow를 도입하기로 한 것이다.

또 많은 기업들이 gitflow를 활용하고, 깃플로우 활용 경험 뿐만아니라 스스로 규칙을 정의하고 도입했다는 것은 경쟁력 있는 경험이라고 생각하기 때문이다.

결론

• 각각의 페이지를 프로세스 단위로 나누어 작업을 구조화할 수 있다,
• merge하기 이전 코드리뷰 단계를 거치기 때문에 최적화된 코드로 배포가 가능하다.
• 오류, 수정, 확인해야되는 상황이 발생하게 될때 발췌하기 쉽다

branch

• main : 배포
• dev : 배포 이전의 개발브랜치
• feature : 페이지단위의 브랜치
  - 네이밍 : feature/페이지명
  • commit : 기능별 커밋을 진행한다.
    • FEAT : 새로운 기능 추가 (FEAT : 페이지명/기능)