브랜치 모델은 어떤 것을 사용하시나요?

[ddumbugie]

안녕하세요.

조용하지요? 잘 지내시죠? 다들 Git과 함께 즐거운 시간을 보내고 계신 거죠?

한가지 제가 고민하고 있는 간단한 질문을 드리고자 합니다.
브랜치 모델을 하나 적용해 보려고 하고 있습니다. 아래 그림과 비슷한 모델이죠.

사실 이제까지는 그냥 마스터에 밀어넣고 중간에 릴리즈용 브랜치하나 가지쳐서 사용했습니다.
위 그림에서 릴리즈 브랜치, 마스터를 분리하는 것은 서로 공감을 했습니다.

오른쪽 분홍색으로 표시된 feature 브랜치를 따서 작업하는 것을 방침으로 정하느냐 마느냐를 가지고 논쟁을 하다가 지치기 시작합니다. 굳이 강제할 필요가 없다. 알아서 하게 내버려두자.

로컬에서 마스터에서 작업하다가 푸쉬하면 똑 같은 것 아니냐?

라는 논리입니다.

제가 이런 사소한 것에 약간 잘 삐지는 편이죠. Git 관련 자료 어디에도 중요 브랜치에 막 밀어 넣어라는 얘기는 없는데, 이것은 너무 복잡하니 단순하게 사용합시다. 그냥 서브버전 처럼.. 이런 주장을 모두 다 하고 있으니, 혼자서 좀 괴롭네요. 돈키호테 같기도 하구요.

어떠신가요? 어떤 경험을 가지고 계신가요?

그럼.

[안승용]

안녕하세요 

저는 그냥 1기능 혹은 1작업 1브랜치를 유지하려고 합니다. 하다 보면 여러 기능을 동시에 하게 되거나 그런 유혹이 생기는데 branch를 분리하고 작업을 하고 master에 머지합니다.

릴리즈 브랜치는 만들지 않고 마스터에서 릴리즈하고 tagging하는 가장 단순한 방법으로 하고 있습니다.

아마 아직 프로젝트 규모가 크지 않아서 그런 것 같습니다.

올려주신 그림 좀 자세히 보아야겠네요.

안승용 드림

2014년 2월 6일 목요일 오후 5시 49분 41초 UTC+9, ddumbugie 님의 말:

[김정훈]

저도 승용님과 같은 방식으로 개발하고 있습니다.

그래도 git은 로컬브랜치라는 개념이 있어서 참 좋더군요.

에전에 CVS나 SVN쓸 때는 로컬브랜치가 없어서 좀 문제가 많았죠.

그렇다고 브랜치를 하자니 머지가 정말 지옥이더군요. 머지하다가 버그를 만드는 경우도..ㅎㅎㅎ

git은 조금 나아졌다고는 하나 그렇다고 조엘이 얘기한것만큼 환상적이진 않더군요.

제 생각엔 브랜치 전략은 머지비용을 고려해봐야 할 것 같은데요. 개발자간 동일 소스를 건드리는 경우가 많고

리팩토링이 활발하게 이루어지는 경우 많은 브랜치는 개발부담을 가중시킬 것으로 생각이 됩니다.

달리 말하면 리팩토링을 억제시키는 악효과가 있을 수도 있구요.

다만 개발인력이 많고 코드에 대한 권한이 명확하게 나누어져있으면 좋은 부분이 있을 것으로 생각됩니다.

저 같은 경우는 개발자가 6명이 넘어가는 경우가 거의 없었고 코드오너쉽을 없애고 활발하게 리팩토링을 권장했기때문에

전략적 브랜치 전략은 경험해보지 못했기 때문에 뭐라고 말씀드리긴 어렵네요. 이쪽은 상희님이 잘 아실것으로 생각되네요.

저 같은 경우는 팀작업에서 브랜치보다는 커밋단위나 커밋메세지를 좀 더 명확하게 해주는쪽이 도움이 많이 되었습니다.

(빅뱅통합이 싫어요~)

좋은 결과 얻으시길!

2014년 2월 6일 오후 5:49, ddumbugie <ddum...@gmail.com>님이 작성:

--
Google 그룹스 'git and workflows' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 git-and-workfl...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.

[ddumbugie]

브랜치 모델을 고민하다가 보니, 이런 논의들이 잘 정리되어 있더군요.

JIRA에서는 별도로 이슈와 git 브랜치를 함께 만들어주는 도구까지 있더군요.
보통 git flow라는 명령어를 통해서 처리하는 방법을 고민하고 있더라구요.


2014년 2월 7일 금요일 오전 8시 56분 29초 UTC+9, 안승용 님의 말:

[ddumbugie]

네, git에서 브랜치나 머지는 너무 가벼운 것이라..

자주 쪼개고 다시 합치자는 전략인 것이죠.


2014년 2월 7일 금요일 오전 10시 19분 49초 UTC+9, 김정훈 님의 말:

저도 승용님과 같은 방식으로 개발하고 있습니다.

그래도 git은 로컬브랜치라는 개념이 있어서 참 좋더군요.

에전에 CVS나 SVN쓸 때는 로컬브랜치가 없어서 좀 문제가 많았죠.

그렇다고 브랜치를 하자니 머지가 정말 지옥이더군요. 머지하다가 버그를 만드는 경우도..ㅎㅎㅎ

git은 조금 나아졌다고는 하나 그렇다고 조엘이 얘기한것만큼 환상적이진 않더군요.

제 생각엔 브랜치 전략은 머지비용을 고려해봐야 할 것 같은데요. 개발자간 동일 소스를 건드리는 경우가 많고

리팩토링이 활발하게 이루어지는 경우 많은 브랜치는 개발부담을 가중시킬 것으로 생각이 됩니다.

달리 말하면 리팩토링을 억제시키는 악효과가 있을 수도 있구요.

생명주기가 짧은 토픽 브랜치를 잘 활용하면 큰 문제가 없을 것 같아요.
 

다만 개발인력이 많고 코드에 대한 권한이 명확하게 나누어져있으면 좋은 부분이 있을 것으로 생각됩니다.

저 같은 경우는 개발자가 6명이 넘어가는 경우가 거의 없었고 코드오너쉽을 없애고 활발하게 리팩토링을 권장했기때문에

전략적 브랜치 전략은 경험해보지 못했기 때문에 뭐라고 말씀드리긴 어렵네요. 이쪽은 상희님이 잘 아실것으로 생각되네요.

저 같은 경우는 팀작업에서 브랜치보다는 커밋단위나 커밋메세지를 좀 더 명확하게 해주는쪽이 도움이 많이 되었습니다.

(빅뱅통합이 싫어요~)

넵..