gitflow를 사용하여 핫픽스를 기능 분기로 다시 통합해야합니까?

프로젝트에 gitflow 를 사용하기 시작 했으며, 새로 만들어진 핫픽스뿐만 아니라 뛰어난 기능 분기가 있습니다. gitflow 워크 플로에 따라 핫픽스는 마스터 및 개발 분기 모두에 적용 되지만 기존 기능 분기에 대해서는 언급되거나 수행되지 않습니다.

그럼에도 불구하고 핫픽스 변경 사항을 기능 지점에 다시 통합하고 싶습니다.

변경 사항을 통합하지 마십시오. 기능 분기에 대한 변경이 필요한 경우 기능 분기의 일부 여야합니다.
피쳐 브랜치로 개발을 다시 병합 하십시오. 이것은 gitflow 워크 플로우를 따르는 것이 가장 좋지만 비 순차적 커밋을 유발합니다.
기능 브랜치를 develop에 리 베이스하십시오 . 이것은 커밋 순서를 유지하지만 rebasing은 일반적인 gitflow 워크 플로우에 완전히없는 것 같습니다.

가장 좋은 방법은 무엇입니까?

git gitflow

피처 브랜치는 일반적으로 수명이 매우 짧으며 변경 사항 을 병합하는 일종의 SCM 냄새입니다 . 피처 브랜치를 완료 (또는 안정화)하고 다시 병합하는 것이 불가능합니까?

— Aaronaught

@Aaronaught 잘 기능이 완료되지 / 아무데도 갈 수 있습니다. 기본 상황은 개발 데이터에 며칠이 걸리는 기능이 프로덕션 데이터에 영향을 줄 수있는 버그를 발견 한 것입니다. 테스트가 작성되었고, 마스터 / 프로덕션에 핫픽스가 적용되었지만 완료되지 않은 기능은 여전히 버그로 인해 손상되었습니다. 절반 완성 된 기능을 개발 메인 라인에 병합 할 것을 제안하고 있습니까? 기능이 팬 아웃되지 않으면 어떻게됩니까?

최신 핫픽스를 선택하기 위해 기능 분기를 개발에 기반 을 두는 데 아무런 문제가 없습니다 . 실제로, 브랜치를 "최신 상태로"유지할 수 있기 때문에 개발 에 대해 기능 브랜치를 자주 리베이스 하는 것이 도움이 될 수 있습니다.

— 웨인 콘래드
소스

예 : 피처 리베이스 기능을 추가 한 gitflow 0.2 공지 사항 을 포함한 좀 더 정황적인 증거를 살펴보면 gitflow 워크 플로우 인 일반적인 git rebase 워크 플로우를 가리키고 있습니다.

흥미 롭군 나는 Gitflow의 전문가라고 말할 수는 없지만 핫픽스는 지점이 아닌 마스터에 대한 단수 커밋이라는 것을 이해했으며 단순히 체리를 사용하여 개발하기로 결정했습니다. 읽는 것은 내가 완전히 틀렸다고 생각했습니다.

— jb510