github에서 의 pull request는 항상 Default Branch(일반적으로 master)에 합치도록 유도하고 있습니다. 그런데 git flow의 모델을 따르다 보면 master에서 pull request를 받기가 심히 애매해집니다. master에 반영된 pull request가 develop 에는 반영되지 않았기 때문에 backward merge를 해야 합니다. 하지만 git flow 툴은 이런 상황을 가정 하고 있지 않기 때문에 조금만 실수 하면 pull request 받은 내용이 버려지고, 반영이 되지 않은 코드로 재변경 되는 일도 있습니다. 이런 실수를 줄이고 오픈소스 기여자(pull request 보내는 사람)이 실수도 덜할수 있는 방법을 꽤나 오래 고민 해보고 테스트 해봤는데요. 다음과 같은 결론이 나왔습니다.
github의 default branch를 develop으로 변경
pull request는 git flow의 feature처럼 취급
이렇게 했을때의 장점은
기여를 하는 사람이 별다른 가이드를 읽지 않더라도 github에서 제공하는 대로 하여도, develop에 합쳐진다.
github의 이슈 기능(자동 이슈 닫기, 마일스톤)과 잘 연동된다.
단점은
git clone 하면 처음 branch가 master branch가 아니라 develop brach이다.
readme.md 가 master버전이 아니라 dev버전으로 보인다.
저는 source 코드로써 배포하기 보다는 npm이나 docker로 배포하기 때문에 단점이 부각되지 않고, 오히려 아무것도 모르는 채로 기여를 시도했을때 개발중인 버전 부터 시작 할수 있다는 장점으로 바뀌었습니다.
readme 또한 크게 바뀔일이 없고 gh-page와 같은 Stable 문서를 다른 방법으로 제공하면 큰 문제가 없기에 이렇게 하는 것이 최선이라는 생각이 들었습니다.
결승전은 끝났지만 "git flow와 github을 어떻게 써야 같이 잘 쓸수 있을까"에 대해 고민한 결과를 공유합니다.
https://github.com/bluemir/wikinote/issues/37
github에서 의 pull request는 항상 Default Branch(일반적으로 master)에 합치도록 유도하고 있습니다. 그런데 git flow의 모델을 따르다 보면 master에서 pull request를 받기가 심히 애매해집니다. master에 반영된 pull request가 develop 에는 반영되지 않았기 때문에 backward merge를 해야 합니다. 하지만 git flow 툴은 이런 상황을 가정 하고 있지 않기 때문에 조금만 실수 하면 pull request 받은 내용이 버려지고, 반영이 되지 않은 코드로 재변경 되는 일도 있습니다. 이런 실수를 줄이고 오픈소스 기여자(pull request 보내는 사람)이 실수도 덜할수 있는 방법을 꽤나 오래 고민 해보고 테스트 해봤는데요. 다음과 같은 결론이 나왔습니다.
이렇게 했을때의 장점은
단점은
저는 source 코드로써 배포하기 보다는 npm이나 docker로 배포하기 때문에 단점이 부각되지 않고, 오히려 아무것도 모르는 채로 기여를 시도했을때 개발중인 버전 부터 시작 할수 있다는 장점으로 바뀌었습니다. readme 또한 크게 바뀔일이 없고 gh-page와 같은 Stable 문서를 다른 방법으로 제공하면 큰 문제가 없기에 이렇게 하는 것이 최선이라는 생각이 들었습니다.
혹시 이와 관련하여 다른 좋은 방법이 있다면 공유 해주시면 감사하겠습니다.