Git branch 전략 설정 2

[choichangyeon]

또 한가지 얘기하고 싶은 내용이 있는데
우아한 형제들 참고자료를 확인해보시면 feature 브랜치에 기능 단위별로 push를 한 이후에
feature 브랜치를 develop 브랜치에 합치는 방식으로 진행하는데,

저희는 그렇게하기보단 자신이 담당한 브랜치를 branch라고 가정했을 때,
branch-layout, branch-feature 등 하위 브랜치를 만들어 작은 단위로 PR을 만들어
develop으로 바로 합치는 것이 아닌 자신의 담당 branch로 합친 이후에 기능을 완전히 만들었을 때 develop으로 합치는 방식이 어떤지 궁금합니다!

// 기존
develop <- Feature/#10-Login (PR 후 merge)

// 새로운 방식
Feature/#10-Login <- Feature/#10-Login-Layout (PR 후 merge)
Feature/#10-Login <- Feature/#10-Login-Feature (PR 후 merge)

...모든 기능이 완료된 이후
develop <- Feature/#10-Login

[choichangyeon]

해당 방식에 대한 이유가 없어서 추가로 얘기를 드리자면
PR을 작게 나눠서 올리기 위함입니다.

PR이 너무 크다면 코드를 리뷰하는 동료 입장에서 많은 내용을 명확히 이해하기 어려울 것입니다.
또한 develop에 무분별한 브랜치 병합이 발생되어 안정성이 떨어질 것으로 생각합니다!

이에 대해서 의견 공유해주시면 감사하겠습니다!

[parkminjo]

이 방법으로 진행하는 것에 동의합니다.
이렇게 진행한다면 해당 기능에 대한 전반적인 내용을 한 번 더 검토해볼 수 있어서, 안정적인 운영이 가능해질 것 같습니다.

[ImJaeOne]

작은 단위로 브랜치를 나눌 경우 CI의 범위를 어디까지 설정할지도 고민해보면 좋을 것 같습니다!

[choichangyeon]

맞습니다! 이 부분은 정확히 git Action의 자동화 설정 방식을 알고 있진 않지만 특정 브랜치를 target으로 설정하는 방향으로 간다면 좋을 것 같습니다!

[ImJaeOne]

간단히 찾아봤는데
GitHub Actions → GitHub Flow(단순한 배포)에 적합
GitLab CI/CD → Git Flow(개발 → 테스트 → 배포 과정이 있는 프로젝트)에 적합
GitLab도 고려해보면 좋을 것 같습니다!

[hye410]

우아한 형제들 방식도 생각해 봤는데요,
예를 들어 장바구니 페이지를 가정해보겠습니다.

• Dev > Feature/cart 분리
• Feature/cart > Feature/cart-layout 분리
• Feature/cart-layout 작업 후 Feature/cart로 머지할 때 PR

이런 단계를 거쳐야 할 거 같아요!
어쩌면 이런 방식이 commit을 자잘하게 나누고 더 작은 단위별로 pr을 받을 수 있을 거 같다는 생각도 듭니다.

단점은 관리해야 할 브랜치가 많아진다는 것이예요.

저는 두 방식 모두 나쁘지 않다고 생각해서 어떤 쪽이어도 동의하겠습니다!
다만 이런 방식도 있을 거 같아서 코멘트로 공유드려보니 참고 부탁드립니다 😊