피쳐 브랜치 리베이스 후 Git 푸시 거부

좋아, 나는 이것이 간단한 자식 시나리오라고 생각했다.

나는이 master지점과 feature지점을. 나는 몇 가지 작업을하고 master, 어떤 작업은 계속하고 , feature더 작업을 master합니다. 나는 이런 식으로 끝납니다 (사전 순서는 커밋 순서를 암시합니다).

A--B--C------F--G  (master)
       \    
        D--E  (feature)

git push origin master원격 작업을 master업데이트하거나 git push origin feature(켜져있을 때 feature) feature작업에 대한 원격 백업을 유지하는 데 아무런 문제가 없습니다 . 지금까지 우린 잘 지내

하지만 지금은 리베이스 할 feature의 상단에 F--G, 마스터에 커밋 I 있도록 git checkout feature하고 git rebase master. 여전히 좋은. 이제 우리는 :

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

문제 : 백업 내가 원하는 순간 새로운 리베이스 feature로 분기 git push origin feature, 푸시가 거부 트리가 리베이스로 인해 변경되었습니다 때문이다. 이 문제는로만 해결할 수 있습니다 git push --force origin feature.

나는 --force그것을 확신하지 않고 사용하는 것을 싫어 한다. 그래서 필요합니까? 리베이스는 반드시 다음 push이 충만 해야 함을 의미 합니까 --force?

이 기능 브랜치는 다른 개발자와 공유되지 않으므로 강제 푸시에 실제로 아무런 문제가 없으며 데이터를 잃지 않을 것입니다. 질문은 더 개념적입니다.

문제는 git push원격 브랜치가 로컬 브랜치로 빨리 전달 될 수 있다고 가정한다는 것입니다. 즉, 로컬 브랜치와 원격 브랜치의 모든 차이점은 끝에 새로운 커밋이있는 로컬에 있다는 것입니다.

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

git rebase커밋 을 수행 하면 D와 E가 새 기본에 적용되고 새 커밋이 생성됩니다. 그것은 rebase 후 당신은 다음과 같은 것을 의미합니다 :

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

이 상황에서 원격 지점은 로컬로 빨리 전달 될 수 없습니다. 이론적으로 로컬 브랜치는 원격으로 병합 할 수 있지만 (이 경우 필요하지 않음) git push빨리 감기 병합 만 수행하면 throw 및 오류가 발생합니다.

그리고 --force옵션은 원격 브랜치의 상태를 무시하고 커밋으로 설정하는 것입니다. 따라서 git push --force origin feature-branch단순히 origin/feature-branchlocal로 재정의하십시오 feature-branch.

내 의견으로는, master당신이 그 지점에서 일하는 유일한 사람이라면 기능 브랜치를 rebasing 하고 원격 리포지토리로 강제 푸시하는 것은 괜찮습니다.

-f 또는 --force를 사용하는 대신 개발자는

--force-with-lease

왜? 원격 지사에서 변경 사항을 확인하기 때문에 좋은 아이디어입니다. James와 Lisa가 동일한 기능 지점에서 작업 중이고 Lisa가 커밋을 추진했다고 가정 해 봅시다. 제임스는 이제 자신의 지사를 리베이스하고 푸시하려고 할 때 거부됩니다. 물론 James는 이것이 rebase에 의한 것으로 생각하고 --force를 사용하며 Lisa의 모든 변경 사항을 다시 작성합니다. 야고보가-임대를 사용했다면 다른 사람이 저지른 일이 있다는 경고를 받았을 것입니다. 리베이스를 추진할 때 누군가가 --force-with-lease 대신 --force를 사용하는 이유를 알 수 없습니다.

대신 "checkout -b"를 사용하면 이해하기 쉽습니다.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

삭제하면 다른 SHA ID가 포함 된 종료 분기를 푸시하지 못합니다. 이 경우 원격 지점 만 삭제하고 있습니다.

이에 대한 한 가지 해결책은 msysGit의 rebasing merge 스크립트가 수행하는 작업을 수행하는 것입니다 . rebase 후에 는와 feature함께 이전 헤드를 병합합니다 -s ours. 커밋 그래프로 끝납니다.

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... 그리고 당신의 푸시 feature는 빨리 진행될 것입니다.

다시 말해, 다음을 수행 할 수 있습니다.

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(테스트되지는 않았지만 맞습니다.)

이 브랜치에는 개발자가 한 명만있을 수도 있고 그렇지 않을 수도 있습니다. 즉, 현재 (리베이스 후) 원점 / 기능과 인라인되지 않습니다.

따라서 다음 순서를 사용하는 것이 좋습니다.

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

예, 새로운 브랜치, 이것은 --force없이 이것을 해결해야합니다. 일반적으로 주요 git 단점이라고 생각합니다.

강제 추진을 피하는 나의 방법은 새로운 브랜치를 만들고 그 새로운 브랜치에 대한 작업을 계속하고 약간의 안정성을 유지 한 후에 리베이스 된 이전 브랜치를 제거하는 것입니다.

• 체크 아웃 한 분기를 로컬로 리베이스
• 재 기반 지점에서 새 지점으로 분기
• 해당 지점을 새 지점으로 원격으로 푸시합니다. 원격에서 이전 분기를 삭제

다른 사람들이 귀하의 질문에 답변했습니다. 브랜치를 리베이스하면 해당 브랜치를 강제로 밀어야합니다.

Rebase 및 공유 저장소는 일반적으로 작동하지 않습니다. 이것은 역사를 다시 쓰고있다. 다른 사람이 해당 지점을 사용 중이거나 해당 지점에서 분기 한 경우 리베이스는 매우 불쾌합니다.

일반적으로 rebase는 로컬 지점 관리에 적합합니다. 원격 지점 관리는 명시 적 병합 (--no-ff)과 함께 가장 잘 작동합니다.

또한 마스터를 기능 분기에 병합하지 않습니다. 대신 마스터로 리베이스하지만 새 분기 이름 (예 : 버전 접미사 추가)으로 리베이스하십시오. 이것은 공유 리포지토리에서 rebasing하는 문제를 피합니다.

지점 git merge master에 어떤 문제가 feature있습니까? 그러면 메인 라인과 분리 된 상태로 유지 한 작업이 보존됩니다.

A--B--C------F--G
       \         \
        D--E------H

편집 : 아 죄송합니다 문제 설명을 읽지 못했습니다. 을 수행 할 때 힘이 필요합니다 rebase. 기록을 수정하는 모든 명령에는 --force인수 가 필요합니다 . 이것은 당신이 일을 잃는 것을 막기위한 비상 안전 장치입니다 (오래 D되고 E잃어 버릴 것입니다).

그래서 당신은 수행 git rebase(부분적으로 숨겨진 없지만 같은 나무 모양을 만들어하는 D과 E더 이상 명명 된 지점에 있습니다)를 :

A--B--C------F--G
       \         \
        D--E      D'--E'

그래서, 당신의 새로운 추진하려고 할 때 feature와 (지점 D'및E' 그것에), 당신은 잃게 D하고 E.

나를 위해 쉬운 단계를 수행하십시오.

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

위의 모든 작업을 수행 한 후 다음 명령으로 myFeature 분기를 삭제할 수 있습니다.

git push origin --delete myFeature

다음은 나를 위해 작동합니다.

git push -f origin branch_name

내 코드를 제거하지 않습니다.

그러나 이것을 피하려면 다음을 수행하십시오.

git checkout master
git pull --rebase
git checkout -b new_branch_name

새 지점에 대한 커밋을 모두 선택할 수 있습니다. git cherry-pick COMMIT ID 새 지점을 밀어 넣으십시오.

OP가 문제를 이해하면 더 좋은 해결책을 찾으십시오 ...

이것은 연습으로 어떻습니까?

• 실제 기능 개발 브랜치에 참여하십시오 (리베이스 및 강제 푸시하지 않으므로 동료 기능 개발자는 당신을 미워하지 않습니다). 여기에서 main으로 변경 사항을 정기적으로 병합하십시오. 메시에의 역사 는 그렇습니다. 그러나 인생은 쉽지 않으며 아무도 그의 일에 관여하지 않습니다.

• 하나의 기능 팀 구성원이 정기적으로 모든 기능 커밋을 실제로 재기 반화하고 강제로 푸시 하는 두 번째 기능 개발 브랜치를 보유하십시오 . 따라서 거의 최근의 마스터 커밋을 기반으로 거의 깨끗합니다. 기능이 완료되면 해당 분기를 마스터 위로 밉니다.

이 메소드의 패턴 이름이 이미있을 수 있습니다.