git은 아래 시나리오를 어떻게 처리합니까?

백엔드 작업과 프론트 엔드 작업의 두 부분으로 나누어 진 작업이 있습니다. 백엔드 변경 사항을 병합하고 병합 될 때까지 기다립니다 (및 주소 피드백). 대기하는 동안 백엔드 변경에 따라 다르고 아직 마스터 브랜치에서 사용할 수 없으므로 프런트 엔드 변경 작업을 실제로 수행 할 수 없습니다.

백엔드 변경 분기에서 검토하는 동안 프론트 엔드 변경 분기로 변경 사항을 가져 오는 가장 좋은 방법은 무엇입니까?

나는 때때로이 문제가 있습니다. 힘내는 매우 유연합니다. 당신이 그것을 할 수있는 한 가지 방법이 있습니다.

첫 번째 지점 featureA을 검토 중입니다.

두 번째 지점 featureB은 개발 중이며 지점 의 코드에 따라 다릅니다 featureA.

featureA지점을 지점으로 병합하십시오 featureB.

featureA분기를 변경 한 featureA경우 featureB분기를 다시 분기로 병합 하여 변경 사항을 통합해야합니다.

또한 featureA기본 트렁크로 먼저 병합해야합니다 . 그렇지 않으면 featureB기본 트렁크로 병합 할 때 실수로 병합 featureA됩니다. 일단 featureA메인 트렁크에 병합 되면 이제는 메인 트렁크에만 의존 하므로 featureA브랜치를 제거 할 수 있습니다 featureB.

피처 브랜치가 서로 의존하지 않을 때 선호하지만 때로는 그렇게하고 롤링해야합니다.

잠깐만, 병합 건너 뛰기

이 방법의 경우, 당신은 할 수 없습니다 당신을 병합 할 feature_a에 feature_b반복.

Rebasing은 다른 답변에서 언급되었지만에 대한 rebasing에만 해당됩니다 master. 귀하의 경우에하고 싶은 일은 :

• 당신의 시작 feature_b에서 feature_a, 즉 :

  git checkout feature_a
  git checkout -b feature_b
  

• 때마다 feature_a그것을 기다리는 동안 변경에 병합 얻을 master, 당신은 리베이스 feature_b 그것에 :

  ... commit something onto feature_a ...
  git checkout feature_b
  git rebase feature_a
  

• 마지막으로 feature_a에 합병 되 자마자 master, 당신은 단순히 새로운 것을 가져 와서 마지막에 그것을 masterrebase feature_a합니다 :

  git checkout master
  git pull origin master
  git checkout feature_b
  git rebase --onto master feature_a feature_b
  

  이 최종 리베이스는 커밋에서 매달려있는 모든 커밋을 feature_a병합합니다 (이것은 병합 된 것과 관련이 없습니다 master) master. 귀하 feature_b는 이제에서 출발하는 간단한 표준 지점입니다 master.

편집 : 의견에서 영감을 얻었습니다. 두 가지 기능에 영향을 미치는 변경을 해야하는 경우 내용을 수정 feature_a한 다음 그림과 같이 리베이스하십시오. 마십시오 하지 두 지점에 두 개의 서로 다른 커밋에서 그것을 확인도 유혹 할 수있는 경우; 으로는 feature_a역사의 일부입니다 feature_b의미 잘못 될 가능성이 나중에 충돌이나 원치 않는 코드의 "부활"로 이어질 것입니다 서로 다른 두 커밋에서 하나의 변화를 가지고.

모든 기능 지점이 종속되어 있고 계속 변경되는 지점이 이미 있습니다. 이라고 master합니다.

피처 브랜치와 동기화 상태를 유지하는 일반적인 방법은 그 위에master 유지 하는 것입니다. 때 master변경하면 일반적으로 git fetch origin master:master && git rebase master지사의 작업 디렉토리입니다.

다른 피처 브랜치에서도 이와 동일한 작업을 수행 할 수 있습니다.

어떤 이유로, 다른 분기로 변경 사항을 이동해야하는 경우 벚꽃 선택할 수 있습니다 귀하의 다른 브랜치의 커밋과 혼합되지 않습니다 커밋.

프론트 엔드 작업이 백엔드 코드에 중대한 의존성을 가지고 있고 백엔드가 마무리되고 마스터에서 수락되기 전에 프론트 엔드에서 작업을 시작하려는 경우, 간단히 프론트 엔드 작업을 기능 분기에서 시작합니다. 마스터에서 프론트 엔드를 분기하는 대신 백엔드 분기.

오래 지속되는 기능 브랜치는 마스터 간헐적으로 변경 사항을 병합해야합니다 ( "검토, qa, 병합- "마스터로"프로세스). 따라서 프런트 엔드 지점에서이 작업을 수행하고 백엔드 작업이 마스터로 승인되면 백엔드에 대한 검토 / 수락의 일부로 자동으로 약간의 변경 사항이 적용됩니다. 마스터에서 다른 코드 변경 사항을 가져옵니다.

백엔드 브랜치가 훨씬 더 많은 작업이 필요하고 마스터에 병합 되기 전에 일정 기간 동안 계속 변경 되는 경우 (예 : 검토 중에 주요 문제가 발견되는 경우) 주기적으로 직접 병합하고 싶을 것입니다 백엔드 브랜치에서 프론트 엔드 브랜치로 (따라서 모든 백엔드 작업을 더 이상 사용되지 않는 백엔드 코드를 기반으로하지는 않습니다). 두 가지 기능을 모두 수행하는 유일한 개발자 인 경우 (쉽게 변경하면 알 수 있기 때문에) 쉽지만 두 기능이 서로 다른 개발자에 의해 병렬로 작동하더라도 괜찮습니다. 의사 소통을 유지하기 만하면됩니다 (어느 쪽이 중요한 종속성이있는 작업을 병렬로 작업하는 경우 어쨌든 필요합니다).

전체 백엔드 브랜치가 버려지고 병합되지 않을 것으로 판명되면 (이것은 거의 발생하지 않는 꽤 큰 거래라고 들립니다), 마스터에서 나오는 새로운 브랜치에 대한 커밋을 체리 피킹하십시오. 백엔드 작업없이, 또는 모든 백엔드 코드를 프론트 엔드 브랜치로 제거하는 리버스 커밋을 적용하십시오. 그러나 내가 알 수 있듯이, 포기하고있는 백엔드를 대체 할 것이 무엇인지 파악한 다음 어떻게 해야할지 결정할 때까지 프론트 엔드 작업을 일시 중지 할 가능성이 높습니다.

여기서 문제가 보이지 않습니다.

master지사 와 함께이 기능을 이미 보유 하고 있으며 기능을 개발 한 다음 병합하는 동안 계속 변경됩니다.

구체적인 예에서는 먼저 feature_xxx_backend지점을 만들고 백엔드 변경 사항을 개발합니다. 이 작업이 완료되면 지사는 master검토를 마치고 검토가 완료되면 병합됩니다 .

따라서 다른 지점을 시작하면 feature_yyy_frontend됩니다. 아마도 브랜치에서 feature_xxx_backend이미 변경 사항이 적용되도록 에서 직접 분기하고 싶을 것입니다 . 그런 다음 분기가있는 것처럼 간단히 프론트 엔드 기능을 개발하십시오 master.

때 feature_xxx_backend따르기는 하겠지만 할 필요가 검토 중에 올 일이 있기 때문에 지점 변화는 단순히 이러한 변경을하고로 병합 예를 들어 feature_yyy_frontend지점. 그런 다음 프론트 엔드 지점에서 계속하십시오.

백엔드 분기에 대한 검토가 완료되면에 병합됩니다 master. 이 시점 에서 지사 를 리베이스 하는 것이 현명합니다 . 따라서 검토자는 이 지사에 기여한 새로운 변경 사항 만 검토하면 되고 백엔드에 대한 변경 사항을 다시 검토 할 필요는 없습니다 (이미 승인 됨). ).feature_yyy_frontendmastermaster

종속 분기가 2 개, 3 개 이상인 경우에도 수행 할 수 있습니다. 의존하는 두 개의 기능 분기가있는 경우 두 기능이 병합 된 파생 분기를 간단하게 작성하십시오. 거기에서 분기하여 세 번째 기능을 개발하고 각 기능 변경시 길을 따라 두 기능 분기를 병합하십시오. 두 기능이 모두 수행되어 파생 된 분기로 병합되면 해당 분기로 리베이스하거나 마스터로 병합 된 경우 마스터로 리베이스하십시오.

Rebasing (위에서 제안한대로)은 실제로 강력하며 변경 사항을 깔끔하게 기록하여 검토를 훨씬 쉽게 만듭니다.

Polygnome에서 언급했듯이 실제로 프런트 엔드 브랜치를 마스터 대신 백엔드 브랜치와 병합 할 수 있습니다. 현재 지점 설정을 사용하더라도 간단하게 다음을 수행 할 수 있습니다.

git checkout frontend
git merge backend

또는 단순히

git merge backend frontend

백엔드 변경이 승인되지 않고 더 많은 작업이 필요한 경우 충돌을 피하기 위해 백엔드에서 프론트 엔드로 업데이트를 병합해야합니다. 변경 사항이 마스터에 적용되면 프런트 엔드를 마스터에 리베이스하여 백엔드 병합 커밋을 제거 할 수 있습니다.

기술적으로는 리베이스로 모든 것을 할 수 있지만 프런트 엔드 브랜치의 커밋 기록이 엉망이됩니다. 내가 어디에서 왔는지, 이것은 나쁜 습관으로 간주됩니다. YMMV

여기에있는 대부분의 답변은 두 번째 지점에서 첫 번째 지점으로 변경 사항을 병합하는 프로세스를 올바르게 설명하지만 해결해야 할 충돌의 양을 최소화하는 방법은 다루지 않습니다.

개별적으로 (예 : featureA및 featureB) 검토하려는 두 가지 큰 변경 사항이있을 때마다 병합되지 않고의 PoC에 대한 초기 피드백을 수집 할 PR을 작성하십시오 featureA.

사람들은이를 신속하게 검토 할 수 있으며 (단지 PoC 일뿐) 목적은 일반적인 설계 또는 접근 방식을 검증하는 것입니다.

그런 다음 피처 A에 대한 작업을 계속하고 풀 요청 및 분기에 대한 풀 요청을 작성하고 피처 B에 대한 작업을 수행 할 수 있습니다.

가장 큰 차이점은 이제 featureA급진적으로 변하지 않을 것으로 예상 할 수 있다는 것입니다 . 디자인과 접근 방식은 이미 검증되었습니다. 코드 검토 및 필요한 변경 사항은 "움직일 수 있습니다. 다른 접근 방식이 필요합니다." 이렇게하면 나중에 병합해야 할 일의 양을 최소화 할 수 featureB에서 featureA의 코드를 '방법에 관계없이 당신은 선택했다.