GitHub 흐름에서, 기능 지점을 다른 기능 지점에 기반을 두는 것이 괜찮습니까?

우리는 프로젝트에서 GitHub Flow 를 사용 하며 대부분 마스터에서 새 기능 분기 를 열고 거기서 작업을하고 PR을 열고 코드를 검토 한 후 다시 마스터로 병합 합니다.

그러나 현재 진행중인 작업은에서 진행중인 다른 문제에 따라 다릅니다 feature-branch-A. 다른 지점에서 내 지점 을 만드는 것이 정숙 합니까, 아니면 GitHub Flow의 정신에 반하는 것입니까?

대안은 내 지점을 마스터에 기반하고 변경 사항을 feature-branch-A(자주) 병합하는 것 입니다.

GitHub 흐름에서 어떤 옵션이 선호됩니까?

기능 분기에서 분기 할 때 따르는 워크 플로는 다음과 같습니다.

1. 만들기 feature-branch-B에서feature-branch-A
2. 그 일을 수행하다 feature-branch-B
3. 더 커밋에 추가하는 경우 feature-branch-A분기 후, 리베이스 feature-branch-B에feature-branch-A
4. 작업을 마치고에 병합 될 feature-branch-B때까지 기다립니다 .feature-branch-Amaster
5. 이후 feature-branch-A에 병합됩니다 masterREBASE, feature-branch-B에master
6. 병합 feature-branch-B에master

위의 워크 플로를 따르면 병합 master한 후 분기 된 것으로 나타납니다 feature-branch-A. feature-branch-A작업을 시작하기 위해가 병합 될 때까지 기다릴 필요가 없습니다 feature-branch-B. 그러나 복잡한 나무 없이도 깨끗한 역사를 얻을 수 있습니다.

다른 지형지 물에서 지형지 물을 만들면 이것이 정상이라고 생각합니다.

그러나 자주하지 마십시오. 나는 이것을 한 주나 두 주 동안 합병을 위해 10 PR을 버린다. 그것은 다른 회원들에게 검토를 위해 완전히 지 쳤고 병합하기도 어려웠습니다. 자식으로 나무를 만들지 마십시오. 오류를 찾는 데 이등분을하는 데 도움이됩니다.

git-flow가 해결하려는 핵심은 주어진 브랜치의 역할과 브랜치 및 병합 대상에 대해 추론하는 능력이었습니다.

이상적으로는 모든 브랜치가 병합 된 코드 라인으로 다시 병합됩니다. 이것은 일반적으로 메인 라인에서 병합입니다 (git-flow에서 이것은입니다 dev). 기능 브랜치 분기 및 dev에서 병합, 브랜치 분기 브랜치 및 dev에서 병합 (에 대한 추가 병합 master). 핫픽스는 지점에서 병합하고 마스터에서 병합합니다 (추가 병합은 다시 dev로).

각 코드 라인은 부모로부터 분기되어 다시 병합됩니다. 코드 라인은 수 는 필요한 경우 언제든지 다른 codelines에서 코드를 빼냅니다.

피처 브랜치의 브랜치가 "그 피처 브랜치에서 문제를 해결하는이 방법을 탐색하고 싶습니다"라면 완벽하게 좋습니다. 기능 분기에서 분기하고 일부 코드를 커밋하고 기능 분기로 다시 병합합니다 (또는 버림).

1. 기능에서 분기
2. 아이디어를 탐구
3. 기능에 병합

그러나 피하고 싶은 것은 다음과 같습니다.

1. 필요한 기능에서 분기
2. 코드 작업
3. 필요한 기능이 완료되면 개발자와 병합
4. 기능 분기에서 기능 (및 추가 커밋) 확인
5. 개발자와 병합

그 이유는 시작과 끝이 일치하지 않기 때문입니다. 이것이 무엇인지 그리고 무엇인지 이해하기가 조금 더 어려워집니다. 불가능하지는 않지만 누군가의 역할을 이해하는 데 약간의 시간이 더 걸립니다.

그러나 이것이 아직 dev에서 찾을 수없는 코드에 의존하는 새로운 기능인 경우 흐름은 다음과 같아야합니다.

1. dev에서 분기
2. 필요한 기능에서 병합
3. 코드 작업
4. 필요한 기능이 완료되면 개발자와 병합
5. 기능 분기에서 기능 (및 추가 커밋) 확인
6. 개발자와 병합

이것은 dev에서 분기로 시작하여 dev 로의 병합으로 끝납니다.

아마도 가장 좋은 방법은 한 기능에서 다른 기능으로의 병합을 피하는 것입니다. 기능을 분기하고 필요한 예비 작업을 수행하고 기다립니다.

1. dev에서 분기
2. 코드 작업
3. 필요한 기능이 완료되면 개발자와 병합
4. 기능 분기에서 기능 (및 추가 커밋) 확인
5. 개발자와 병합

이는 가장 안정적인 분기 및 코드 세트를 제공합니다.

향후 작업에서 고려해야 할 사항은 구현 코드가 완전하지 않더라도 다른 기능과의 상호 운용성을 위해 필요한 인터페이스를 게시하는 기능을 보유하는 것입니다. 이것은 dev로 병합 된 다음 필수 기능은 미래 기능과 마찬가지로 해당 인터페이스에서 작동 할 수 있습니다. 이를 통해 필요한 기능이 개발자와 병합되기를 기다려야 할 때보 다 미래 기능이 인터페이스에 대한 코딩, 인터페이스를 구현하는 스텁에 대한 테스트 등을 더 진행할 수 있습니다.

기능 분기는 일반적으로 트렁크 (개발 / 마스터)보다 안정성이 낮은 것으로 간주되므로 작업을 기반으로하는 경우 평소보다 더 근본적인 변경을받을 수 있습니다.

또한 분기가 밀려 나면 일반적으로 눈살을 찌푸리게하지만 기능 분기를 상위 분기에 리베이스하여 더 좋은 기록을 얻는 것은 드문 일이 아니지만 추가 분기가 매달려 있으면 더 복잡해집니다. '본질적으로 부모 브랜치 소유자를위한 새로운 제한과 잠재적 인 두통을 유발하고 있습니다.

즉, 그것에 대한 엄격한 규칙은 없습니다. 이것들은 결국 패턴과 모범 사례입니다.

편집 : 질문의 일부를 놓쳤습니다. 마스터를 기반으로 기능 분기를 자체 분기로 병합하면 실제로 위에서 언급 한 문제를 피할 수 없으며 실제로 더 복잡한 역사를 만들 수 있습니다.

따라서 내가 당신의 신발에 있었고 기능 a가 끝날 때까지 일을 연기하거나 다른 것을 먼저 할 수 있다면 그렇게 할 것입니다.