
우리는 마스터 브랜치를 갖고 기능 브랜치에서 기능을 개발하는 두 명의 개발자로 구성된 팀입니다. 릴리스할 때 마스터의 분기를 분기 해제합니다. 모든 버그 수정은 마스터에서 수행된 다음 관련 릴리스 브랜치로 선별됩니다.
우리는 다음에 설명된 대로 롤백하고 양분할 수 있는 각각의 새로운 기능에 대해 원자적 병합 커밋을 원합니다.https://gist.github.com/jbenet/ee6c9ac48068889b0912. 이는 우리에게 다음과 같은 역사를 제공해야 합니다.
* aa55ffe - (HEAD, master) D
* 88425f8 - C
* 7bc519f - Merge branch 'feature-X' into master
|\
| * 9364e61 - feature-X: 2
| * bc76674 - feature-X: 1
|/
* 88425f8 - B
* 7bc519f - Merge branch 'feature-Y' into master
|\
| * 0e0deea - feature-Y: 4
| * 11079b5 - feature-Y: 3
| * 9364e61 - feature-Y: 2
| * bc76674 - feature-Y: 1
|/
* c765ae3 - A
문제는 기능 분기의 원격 버전을 추적하는 동일한 기능을 작업하는 여러 개발자가 있을 때 발생합니다. 일부 개발자가 해당 기능을 작업하는 동안 마스터에서 기능을 개발하는 동안 버그 수정이 발생할 수 있습니다. 이제 기능 브랜치에 해당 버그 수정 사항을 포함하려고 합니다(예: 버그가 수정된 마스터에서 새 상태의 기능 브랜치를 다시 리베이스합니다.).
원격 추적 분기를 손상시켜 깨끗한 기록과 다른 기능 개발자의 작업 복사본을 망치지 않는 방법이 있습니까?
Fx 기능 브랜치에서 버그를 선택하고 기능 브랜치의 새 리베이스 버전을 마스터에 병합하기 직전에 원격 추적 브랜치를 고아로 만드는 최종 리베이스 후에 git이 자동으로 버그를 해결하도록 할 수 있습니까?
답변1
기능 브랜치에서 버그를 선택하고 git이 자동으로 해결하도록 할 수 있습니까?
수정 사항으로 인해 충돌이 발생하지 않으면 이 방법이 작동할 수 있습니다. git clone https://gist.github.com/jbenet/7959265
, 기록을 확인하고 거기에 붙여넣은 리플로그를 읽어보세요.
체리 피킹 시 충돌을 해결하는 경우 PR을 병합하기 직전에 마스터 위에 리베이스할 때 커밋을 수동으로 제거할 수 있습니다(충돌을 해결하는 커밋 메시지에 태그를 지정하거나 미리 알림을 작성할 수 있음).
하지만 IMO에서는 핫픽스를 사용할 수 있을 때 마스터 위에 기능 분기를 리베이스했습니다. 이는 마스터에서 변경 사항을 가져오는 것과 동일합니다(최근에 병합된 다른 기능 분기 포함). 따라서 지점이 오래된 것에 대해 걱정할 필요가 없습니다. 병합된 핫픽스를 제거하거나 자주 리베이스하는 등 팀에서 처리하려는 작업에 따라 다릅니다.
답변2
기능 브랜치에 버그 수정이 정말로 필요하다면 버그 수정 브랜치를 병합하세요. bisect/rollback/FUD에 대한 이야기는 제 경험상 bisect가 복잡한 병합 기록을 잘 처리합니다. 해당 게시물에서 제안된 모델은 인위적인 문제(예: 질문하는 문제)를 생성하며 말 그대로 유일한 이점은 더 깨끗하다는 것입니다.찾고역사. 우리는 리베이스하지 않는 것의 이점을 깨닫기 전까지 몇 년 동안 이 모델을 사용했습니다. 나는 내 자신의 기록(커밋 스쿼시, 커밋 메시지 변경 등)을 정리해야 할 때 리베이스하지만 다운스트림의 다른 사람에게는 영향을 주지 않습니다(예: 내가 브랜치에서 단독으로 작업하는 경우).