[BrainStorm] 새로운 Git 전략에대한 고찰

GitFlow 전략을 이해하고 사용하기 전부터 Git을 사용하고 있었는데요

그때를 생각하면 마치 SVN처럼 Git을 사용하며 Git은 commit과 push가 나눠져있어서 좋아라고 하던 과거가 떠오르네요

적지않은 시간동안 Git Flow를 사용하며 개인적으로 느꼈던 감정과 보완되면 좋을만한 점에대해 이야기해보려고 합니다.

 

1. GitFlow 전략은 무엇인가?

Git은 브랜치기반의 버전관리 시스템이기에 브런치를 어떻게 생성하고 병합할지에 대한 전략이 필요합니다.

그런 전략들 중 GithubFlow와 함께 가장 많이 사용되는 전략이며 업계의 표준으로 자리잡고 있습니다.

 

2. 장점

티켓단위로 브런치를 생성할 때 충돌을 최소화하며 독립적인 환경을 구축할 수 있습니다.

또한 개발서버와 운영서버의 배포시에도 전략적인 배포가 가능하도록 도와줍니다.

마지막으로 여러단계를 거쳐 검증된 브런치를 안전하게 병합할 수 있습니다.

 

3. 생각해볼만한 지점

대부분의 상황에서 GitFlow전략은 유용한데, 머지헬에는 취약할 수 밖에없습니다.

예를들어 동시에 진행되는 프로젝트가 있고 어떤 프로젝트가 먼저 마무리가 될지 모르는 상황 혹은 먼저 배포되기로 했던 프로젝트가 지연되는 상황에서는 난감한 일이 발생할 수 있습니다.

이것은 GithubFlow같은 trunk-based development 전략도 막을 수 없는 일입니다.

이런경우 Revert, Charry-Pick, feature-Toggle 등의 방법을 사용할 수는 있지만 부자연스러움이 느껴지는건 여전합니다.

 

4. 어떻게 해결할 것인가?

현재 사용하고 있는 전략은 아니고 검토중인 전략인데

GithubFlow 같은 trunk-based development 와 큰틀에서는 통일하지만 GitlabFlow처럼 PreProduction 을 끼워넣습니다.

그러나 GitlabFlow와 차이점이 있다면 PreProd 를 Prod에 병합하지 않는다는 점입니다.

 

이렇게 되면 모든 GithubFlow와 같이 Prod는 깔끔한 상태로 관리되면서 QA팀은 PreProd를 통해 충분한 테스트를 진행할 수 있을것으로 기대됩니다.

물론 PreProd와 Prod의 차이가 발생하는 경우 문제가 발생할 수 있기에 충분한 테스트를 거치거나 Prod와 Feature 사이에 Beta 단계를 둘 수도 있습니다만 브런치관리 레벨을 많이 가져가는게 능사는 아니라고 생각합니다.