Git Flow와 같은 병합 전략은 실제로 반 패턴입니까?

우리 회사는 Git을 사용하고 있으며 독특한 분기 방식을 사용하고 있습니다. 작업은 마스터에서 수행되며 지점은 릴리스를 위해 예약됩니다. 반복에서 수행 된 모든 작업이 지점으로 들어가는 한 제대로 작동하지만 중요한 생산 문제가 발생하면 작업이 두 지점 모두에서 이루어 지도록해야합니다.

최근에, 우리는 그 지점들과 함께 "재미"를 가지고 있습니다. 관리상의 골칫거리로 모든 작업이 모든 브랜치에 적용되도록하고 한 브랜치에서 수정 된 일부 버그는 누군가 지적 할 때까지 마스터로 만들지 않습니다.

나는 Git Flow 를 잠시 만났고, 그것이 문제에 대한 해결책이 될 것이라고 느꼈다. 코드는 릴리스까지 완전히 퍼지지 않거나 코드가 다시 내려갑니다. 유일하게 파악한 것은 내 리더가 이런 종류의 개발이 반 패턴 (anti-pattern)이었다고 언급했다.

나는 내가 동의한다는 것을 완전히 확신하지 못하고, 그것을 제기 한 이후로 일이 정상적으로 재개되었다. 최근에 우리는 이것으로 몇 가지 큰 어려움을 겪었습니다.

알고 싶습니다. 왜 이런 종류의 개발 체계가 반 패턴으로 보일까요? 가 정말 안티 패턴?

그는 주로 모델의 피쳐 브랜치 측면을 참조합니다. 피처 브랜치는 오래 전에 브랜치가 몇 달 동안 지속되고 버전 관리 시스템이 병합되어 생명을 구할 수없는 반 패턴으로 선언되었습니다. 1 ~ 2 주간 지속되는 기능 분기는 특히 해당 기간 동안 기능 분기 에서 계속 병합하는 경우 문제가 훨씬 줄어 듭니다 develop. 그보다 훨씬 긴 것은 여전히 ​​권장되지 않습니다.

git flow의 기능 분기 측을 사용하지 않더라도 다른 부분은 깔끔하게 병합되고 변경 사항이 올바른 방향으로 전파되도록하는 데 유용합니다.

병합은 재밌는 일입니다. 덜 자주 수행 될수록 더 어려워 질수록 더 어려워 질수록 더 많은 사람들이 두려워 할 것입니다.

해결책은 가지가 너무 많이 벗어나거나 가지를 사용하지 않는 것입니다.

사람들이 이것을 이해한다면 아마도 병합에 많은 문제가 없을 것입니다. 그렇지 않다면 – 교육이 없으면 가지가 좋은 생각이 아닐 수도 있습니다.