Gitflow에 대한 생각 feat. agile

대학과제로 3명이서 팀프로젝트를 한 적이 있었다.

 

팀원들은 Github를 써서 나중에 마지막으로 merge 하자고 했다.

 

한명씩 master branch로부터 각자의 repository를 만들어 마지막에 merge 하자고했다.

 

그때는 브랜치 전략에 대한 생각이 없었으므로 그냥 마지막에 각자 local repository에서 결과물을 merge하면

 

되겠지라고 생각했는데, 막상 마지막날에 merge하고 배포할때 충돌이 많이 일어났던 경험이 있다.

 

우리는 자연스럽게 폭포수방법론(Waterfall Method)를 쓰고 있었던 것이다.

 

중간에 프로토타입의 테스트 과정 없이 마지막에 결과물을 테스트를 하고

한꺼번에 고치려고 하니 마지막 출시에 가까워졌을때 굉장히 당황을 많이 했고,

중간중간 배포를 통해 추가기능을 넣는건 생각도 못하고 소통도 많이 단절된 경험이 있었다.

 

지금 생각해보니, 만약 그때, 애자일방법론(Agile method)을 써서 전체개발기간이 4달이었으므로 Sprint(2주)

간격으로 프로토타입을 만들고, 각자의 Repository를 pull request 하고, 서로의 코드를 리뷰하고, 

제품을 한번 실행해보고 Agile답게 기능에 대한 피드백을 얻고, 다시 유연하게 새로운 Sprint를 계획하고

실행하는 방식으로 Major Version, Minor Version으로 Versioning convention을 만들고 개발을 진행

했으면 엄청난 개발 생산성과 결과물의 질적인 향상이 이뤄지지 않았을까 하는 생각이 들었다.

 

그 Agile 방법론을 적용하기 위한 Implementation에서 필수적인 요소는 GitFlow라고 생각한다.

 

 

 

먼저 Master Branch를 만들고, 개발환경을 셋팅한다.

 

 

그다음, 각자의 Repository를 만들고, 각자의 Repository에서 위의 그림과 같이

Master, Develop, Feature, Release, Hostfix 브랜치를 만들어서

최종적으로 Master branch를 Pull request해서 merge하는 전략을 가졌다면

다시 한번 강조하지만, 생산성과 결과물에서 엄청난 향상을 가졌으리라 확신한다.

 

애자일, 스크럼, 코드리뷰, CI/CD, Git-flow, 테스트코드, 기술공유, 스타일가이드, 사내 스터디

 

위의 열거된 요소는 개발문화가 잘 갖춰진 좋은 회사들의 공통점이라고 한다.

 

 

Agile, Sprint, Branch Strategy의 필요성을 깊이 깨달았다.