자식 흐름은 : 다시 개발

Question

에 병합에서 릴리스 브랜치에서 만든 몇 가지 변경을 방지하는 방법에 문제는 git-flow 방법론에 대한 몇 가지 가장자리 경우가

나는이 같은 전형적인 자식 흐름 역사의 일종 :

 o---o---o---o [release-3.5.0] 
    /
----o---o---o---o---o [development] 

망할 놈의 흐름은 출시 준비가 릴리스 3.5.0 지점 개발 에 병합 우리에게 말했다. 그래서, 결국 우리는 ALL을 개발 분기점으로 릴리즈 할 것입니다. 이제

 o---o---o---o 
    /   \ 
----o---o---o---o---o [development] 

우리가 상상 커밋 'X'출시 분기에 우리가하지 예를 들어이 이미 개발에 고정되어 해킹/핫픽스 또는 다른 어떤 종류이며, 개발 지점에서 싶어 무엇 더 정상적인 방법 (예 : 커밋 Y)

 o---X---o---o [release-3.5.0] 
    /
----o---o---o---Y---o [development] 

그렇다면이 문제를 어떻게 처리해야할까요? 이 커밋 (또는 커밋)이 개발로 돌아 가지 않도록하는 방법은 무엇입니까?

1) 당신이 당신의 개발 지점에 릴리스 브랜치를 리베이스 수있는이 모드에서 git rebase -i

를 사용하고 X 번째 커밋 제외

:

Answer 1

답변이 rebase 추천 및/또는 스쿼시가 작동/복귀/병합하는 동안, 나는 개인적으로 더 나은 답이있을 거라고 생각 :

git checkout development 
git merge --no-commit release-3.5.0 
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts 
git commit 

Answer 2

당신은 몇 가지 옵션이 있습니다.

경고이 경우 기존 복제 된 저장소를 망칠 것입니다.

2) 하나 하나를 저지른 선택 할 수있을 것입니다이 모드에서

git cherry-pick를 사용합니다. 당신이 항상 완전히 해제 (-like) 가지를 병합 할 Is it possible to exclude specific commits when doing a git merge?

Answer 3

을 같은 시나리오에서 :

3) 별도의 지점에 git rebase -i를 사용하고이 답변에 명시된 바와 같이, 나중에 병합. 그러므로 누락 된 부분이 없는지 확인하십시오.

그러나 병합 중에 내용을 자유롭게 수정할 수 있습니다 (일부 변경 내용을 삭제하거나 다시 실행하는 것을 포함하여). 예제의 경우, 분기를 병합하고, 마음에 들지 않는 커밋을 되돌리고, 스쿼시를 병합 커밋으로 되돌립니다. 분명히 해당 작업의 병합 커밋 메시지에 메모를 작성하십시오.

수정 프로그램이 이미 devel에있는 경우 병합은 건너 뛰거나 devel 버전을 선택하여 충돌을 해결합니다.

역사적인 쇼를 두 번째 그림으로 표시하고 상태를 가장 좋게 만드는 것이 요점입니다.