git-flow 가 복잡하기 보다 버전관리에 대한 이슈와 요구사항이 복잡해진것 같습니다. git-flow 가 http://nvie.com/posts/a-successful-git-branching-model/ 에서 이야기하고 있는 경험적인 브랜치 전략이다 보니 사용함에 있어 여러 오해와 구멍이 있다고 생각합니다. 전 개인적으로 git-flow 의 브랜치 전략이 검증된 모델이라는 점에 극 공감을 하고 있습니다.

허나 사용하는 입장에서 git-flow 가 단순한 command 에 대한 alias 정도로만 인식 되어져 도구 뒤에 깔려있는 전략과 이유에 대해서는 배제되고 있다고 생각합니다.

git-flow 를 사용하기 위해서는 전제가 필요한데 이 전제를 무시 한 채 사용하기 때문에 복잡해지고 원래의 효과과를 보지 못하게 되는것 같네요.

이 같은 도구나 무엇인가를 결정할 때 가장 중요한 점은 Context라고 생각한다. 현재 조직의 규모, 서비스의 상태, 프로젝트에 참여하고 있는 구성원의 지식 수준 등등 다양한 Context를 고려해 최선의 방법이라고 생각한다.

이런 관점에서 봤을 때 git-flow가 적합할 수도, 적합하지 않을 수도 있다고 본다. 이 글과 같이 안정장치에 대한 필요성이 낮은 환경에서는 github flow와 같이 단순한 전략을 취하는 것도 좋은 선택이라고 본다.

안정 장치를 어느 수준으로 볼 것이냐에 따른 것인데 github flow의 경우 배포하기 전에 리뷰라는 안정 장치를 두었다고 생각한다. 리뷰를 통해서도 충분히 안전하다고 판단했기 때문에 선택한 전략이라고 본다.

그렇다면 @진우, @하윤아빠 둘이 몸담고 있는 조직의 전략은 어떠해야 할까? 내가 결정할 수 있는 권한이 있는 것은 아니지만 내가 결정할 수 있다면 지금 단계에서는 git-flow와 같은 도구를 통해 안정 장치를 마련하는 것이 좋다는 생각이 든다. 가장 큰 이유는 아직까지 개발자들의 역량이나 workflow가 리뷰를 통해 안정 장치를 마련할 수 있는 수준은 아니라고 판단되기 때문이다. 따라서 시스템을 통해 명확하게 분리해야 한다고 생각한다. 또한 이미 100명이 넘는 개발자가 같은 소스 코드를 바라보고 있기 때문에 이 또한 시스템을 통한 분리가 필요하다고 본다. 모듈화가 잘 되어 있어 각 저장소를 바라보는 개발자가 10명 전후로 제한된다면 github flow도 괜찮은 전략이지만 현재는 모듈화도 부족한 상태이기 때문에 git-flow의 도입은 더 필요하지 않을까라고 생각한다.

난 제 3자의 입장이기 때문에 마음껏 씨부려봤다.

깃의 브랜칭과 배포에 대한 전략은 회사의 상황에 따라 달라지는 것이 기본이라 생각합니다. 이 기본전략은 개발팀의 협의를 통해서 결정을 하고 운영되어야 합니다. 그렇겠죠?

위의 브랜치 전략은 git-flow를 약간 응용해서 제가 운영하고 있는 git 브랜칭 전략입니다. 실제 개발은 develop 브랜치에서 진행되고 있고, 아래와 같은 형태로 브랜치들을 처리하고 있습니다.

• master : 솔루션의 큰 변경사항이 있을 경우에 대한 태깅용 브랜치
• develop : 로컬 개발 및 테스트 브랜치
• feature/기능 : 기능 개발할 때마다 생성
• production/dev : 개발서버 배포 브랜치
• production/a-company : A 고객사 배포 브랜치
• production/b-company : B 고객사 배포 브랜치
• production/{next}: 다음 고객사 배포 브랜치

위와 같은 브랜칭 전략을 구성하게 된 이유는, 저희 회사에서 제공하고 있는 솔루션의 변경이 생겼을 때를 고려해서 고객사별로 브랜치를 구성하고 변경사항을 관리하기 위해서 입니다. 고객사가 늘어나게 되면 헬이 되겠지만, 나름 문서화를 잘하고 명명규칙을 정하면 커버가능하겠다는 나름의 배짱 플레이가 있습니다. 깃의 '자유로운 브랜칭과 강력한 머징'은 이런 전략을 사용가능하도록 해줍니다. 지금은 수동으로 하고 있지만, 이를 자동화해줄 스크립트를 작성해서 간단하게 실행시킬 수도 있습니다(처음에 작성할 때는 번거롭겠지만).

소스코드의 버전관리(브랜칭) 정책과 배포에 대한 고려가 제일 우선이 되어야 여러가지 문제들의 실마리를 찾을 수 있을 겁니다.

예를 들어, 상시배포의 경우에는, 상시배포에 사용하는 브랜치(ex: freq-deploy)와 배포전략(개발서버에는 freq-deploy 브랜치를 통해 빌드배포를 진행한다, 이때 젠킨스에서는 SCM polling'소스코드의 변경이 있는지를 일정시간마다 확인해서 변경이 있을 때 빌드-배포 진행'을 걸어두거나 해당하는 작업에 대한 실행권한을 가진 계정으로 실행한다 등)의 전략을 수립하는 것이죠.

그리고 이런 전략은 팀원간에 공유되고 학습-체득화되어야 합니다. 누군가가 이 전략을 위반해서 자기 마음대로 처리를 하면 망가지겠죠. 혹은 github.com(https://github.com),,) bitbucket.org(https://bitbucket.org),,) yobi(http://yobi.io)와와) 같은 서비스 등을 통해서 배포에 사용되는 저장소와 개발자의 저장소를 분리하고 Pull Request하여 처리하는 전략을 짤 수도 있을 겁니다.

중요한건! 개발팀 내의 소스버전관리 및 빌드배포 전략을 확립하는 것입니다. ^^;

git-flow는 도구일 뿐, 중요한 건 그 도구를 어떻게 쓸 지를 결정하는 거죠. 이왕이면 그 도구의 목적에 대해서 제대로 알고 시작하는 것이 좋겠죠.

@김지헌 좋은 말씀 고맙습니다.

공유해주신 브랜칭 전략에서 production이 고객사마다 분리되어있는데 production/dev와 feature와는 어떤식으로 싱크가 되는지 궁금하네요.

추가로,

그리고 이런 전략은 팀원간에 공유되고 학습-체득화되어야 합니다. 누군가가 이 전략을 위반해서 자기 마음대로 처리를 하면 망가지겠죠.

이 부분이 제일 우려되는 부분입니다. 전략에 대해 모두가 공감하고 같은 프로세스를 따르면 좋은데 각자 편한(익숙한) 방법으로 하려는 상황이 자주 발생하게 되는것 같습니다. 권한제어 등 시스템적인 부분으로 제어가 필요한 부분이겠지요.

@진우

feature 는 git-flow의 feature 브랜치 전략입니다. 기능 개발을 할 때, develop 브랜치에서 브랜칭해서 기능개발을 완료하면 'git flow feature finish 기능-브랜치' 명령을 통해 사라지는 브랜치죠. ^^;

로컬에서 개발할 때는 develop에서 개발을 하고, 개발서버에 배포를 할 때는 develop에서 브랜칭된 production/dev 를 기준으로 배포하고 있습니다. 그래서 항상 deveop 브랜치에서 production/dev에 우선 머징하고 개발서버에 배포해서 확인한 후에, develop 에서 production/a-company, production/b-company 으로 머징하고 배포하는 작업을 하고 있습니다.

별다른 것은 없습니다. ^^;;

production/dev 같은 경우에는 고객사와 같은 서버환경을 가진 개발서버라서 여기서 정상동작 하면, 고객사들의 서버에서도 정상동작한다는 가정을 하고 진행되고 있습니다.

git flow vs github flow 에 대해서 비슷한 고민을 하다보니 '프로젝트가 상시 배포가 가능한가.'라는 문제가 떠오릅니다. 별도의 안정화 과정이 개발 프로세스에 영향을 줄 만큼 유의미하게 길고 자동화가 안되어있다면 필연적으로 release-* 브랜치를 두고 master / develop을 분리하여 격리하는 것이 타당하다고 보이나, 반대로 충분히 짧은 시간 안에 지속적으로 안정화시킬 수 있다면 굳이 release-* / develop을 두어 분리하는 것이 무의미하다고 판단할 수 있겠죠.

즉 지속적인 상시 배포를 해야하는지, 또 실제로 안정적인 상시 배포가 가능한 상태인지가 두 브랜칭 전략을 결정하는 요인이 아닐까요?