기본 재배치 후 분기로 푸시할 수 없음

기본 재배치 후 분기로 푸시할 수 없음

우리는 git를 사용하고 마스터 브랜치와 개발자 브랜치를 가지고 있습니다.새 기능을 추가한 다음 커밋의 기본을 마스터로 바꾸고 마스터를 CI 서버에 푸시해야 합니다.

문제는 기본 재배치 중에 충돌이 발생하면 기본 재배치가 완료된 후 원격 브랜치를 풀링할 때까지 원격 개발자 브랜치(Github)로 푸시할 수 없다는 것입니다.이로 인해 커밋이 중복됩니다.충돌이 없을 때는 예상대로 작동합니다.

질문: 기본 재배치 및 충돌 해결 후 중복 커밋을 만들지 않고 로컬 및 원격 개발자 분기를 동기화하려면 어떻게 해야 합니까?

설정:

// master branch is the main branch
git checkout master
git checkout -b myNewFeature

// I will work on this at work and at home
git push origin myNewFeature

// work work work on myNewFeature
// master branch has been updated and will conflict with myNewFeature
git pull --rebase origin master

// we have conflicts
// solve conflict
git rebase --continue

//repeat until rebase is complete
git push origin myNewFeature

//ERROR
error: failed to push some refs to 'git@github.com:ariklevy/dropLocker.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

// do what git says and pull
git pull origin myNewFeature

git push origin myNewFeature

// Now I have duplicate commits on the remote branch myNewFeature

편집

따라서 워크플로우가 중단되는 것처럼 들립니다.

developer1 나의 NewFeature developer2 그의 NewFeature에서 일하는 것은 둘 다 master를 메인 브랜치로 사용합니다.

developer2가 내 새 기능을 그의 새 기능에 병합합니다.

developer1은 기본 재배치하고 충돌을 해결한 다음 내 새 기능을 위해 원격 분기에 강제 푸시합니다.

며칠 후, developer2는 나의 새 기능을 그의 새 기능에 다시 병합합니다.

이것이 다른 개발자들이 developer1을 싫어하게 만들까요?

먼저, 여러분과 여러분과 함께 일하는 사람들은 주제/개발 부문이 공유 개발을 위한 것인지 아니면 여러분만의 것인지에 대해 동의해야 합니다.다른 개발자들은 언제든지 리베이스될 것이기 때문에 제 개발 브랜치에서 병합하지 말아야 한다는 것을 알고 있습니다.일반적으로 워크플로우는 다음과 같습니다.

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

그런 다음 원격으로 최신 상태를 유지하려면 다음 작업을 수행합니다.

 git fetch origin
 git checkout master
 git merge --ff origin/master

제가 이 일을 하는 이유는 두 가지입니다.첫째, 개발 지점에서 전환할 필요 없이 원격 변경 사항이 있는지 확인할 수 있기 때문입니다.둘째, 저장되지 않았거나 커밋된 변경사항을 덮어쓰지 않도록 하는 것이 안전 메커니즘입니다.또한 마스터 분기로 빠르게 병합할 수 없는 경우에는 누군가 원격 마스터를 재조정했거나(이 경우 심각한 로그가 필요함) 실수로 마스터를 커밋하여 끝을 정리해야 합니다.

그런 다음 원격에서 변경 사항이 있고 최신 버전으로 빠르게 전달하면 기본값을 변경합니다.

git checkout devel0
git rebase master
git push -f origin devel0

그러면 다른 개발자들은 최신 버전의 개발 지점을 다시 기반으로 삼아야 한다는 것을 알게 됩니다.

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

이로 인해 훨씬 더 깨끗한 이력을 얻을 수 있습니다.

o-----o                                 master
       \
         o-----o-----o                  devel0
                      \
                        o-----o-----o   devel1

마음대로 앞뒤로 커밋을 병합하지 마십시오.중복된 커밋을 생성하고 기록을 따를 수 없게 만들 뿐만 아니라 특정 변경 사항에서 회귀를 찾는 것이 거의 불가능해집니다(그래서 처음부터 버전 제어를 사용하는 것이죠?).당신이 겪고 있는 문제는 바로 이것을 한 결과입니다.

또한 다른 개발자들이 당신의 개발 지점에 커밋을 하는 것처럼 들립니다.이것을 확인해 주시겠습니까?

주제 분기가 다음으로 수락될 준비가 되었을 때만 병합할 수 있습니다.master.

사이드 노트에.여러 개발자가 동일한 리포지토리에 커밋하는 경우에는 개발자 개발 분기를 구분하기 위해 모두 명명된 분기를 갖는 것을 고려해야 합니다.예:

git branch 'my-name/devel-branch'

따라서 모든 개발자 주제 분기는 고유한 중첩 집합 내에 있습니다.

분기 끝에 커밋을 추가할 것으로 예상되는 라인 아래로 커밋을 이동했기 때문에 강제로 푸시해야 합니다.git push -f origin myNewFeature당신의 문제를 해결해 줄 것입니다.

팁: 위는 힘을 가하는 합법적인 사용입니다.절대로 공개적으로 액세스할 수 있는 저장소에 기록을 다시 쓰지 마십시오. 그렇지 않으면 많은 사람들이 당신을 싫어하게 될 것입니다.

여기서 명심해야 할 주요 사항은 뒤에서 풀과 리베이스가 무엇을 하고 있는지입니다.

풀은 기본적으로 두 가지 작업을 수행합니다. 가져오기와 병합입니다.--rebase를 포함하면 병합 대신 기본 재배치가 수행됩니다.

기본값은 분기된 이후의 모든 로컬 변경사항을 저장하고, 분기를 대상에 대한 최신 커밋으로 빠르게 전달하고, 변경사항을 맨 위에 순서대로 표시하는 것과 거의 비슷합니다.

따라서 기본 재배치를 수행할 때 병합을 통해 얻을 수 있는 하나의 충돌 해결 메시지와 비교하여 여러 충돌 해결 메시지가 표시될 수 있습니다.그렇지 않으면 커밋을 보존하기 위해 재조정되는 각 커밋에서 충돌을 해결할 수 있습니다.)

기록을 다시 쓰는 것이기 때문에 원격 분기에 재조정된 변경사항을 푸시하지 않을 수 있습니다.물론, 거의 항상 예외가 있기 때문에 조금도 강하지 않습니다.예를 들어 특정 환경에서 작업하려면 로컬 저장소의 원격 버전을 유지 관리해야 하는 경우.

이렇게 하려면 다음과 같이 강제로 변경 내용을 적용해야 합니다.

git push -f origin newfeature

또는 관리자가 강제 적용 기능을 제거하여 다음을 삭제하고 다시 만들어야 하는 경우도 있습니다.

git push origin :newfeature
git push origin newfeature

두 경우 모두 원격 지점에서 다른 사용자가 사용자와 공동 작업을 수행하는 경우 사용자가 수행하는 작업을 확실히 알고 있어야 합니다.즉, 처음에는 병합과 함께 작업하고 작업 분기를 마스터하고 제거하기 직전에 관리하기 쉬운 커밋 형식으로 재구성할 수 있습니다.

다음과 같은 이점을 활용하면 거의 항상 Git의 GC에 의존할 수 있습니다.

git reflog

이는 모든 기본 재배치/충돌 관리에서 길을 잃었을 때 보다 안정적인 상태로 재설정할 수 있기 때문에 생명을 크게 절약할 수 있습니다.

강제 푸시를 수행해야 합니다.git push -f origin myNewFeature

아, 그리고 사람들이 당신의 개발 부서에 기반을 두지 않도록 하는 것이 좋습니다. 보통 당신은 역사를 다시 쓰는 지점을 전혀 출판하지 않아야 합니다(또는 한 번 출판되면 역사를 다시 쓰지 않습니다).한 가지 방법은 다음과 같은 지점 이름을 사용하는 것입니다.wip/myNewFeature그리고 나서 그것을 언급합니다.wip분기는 때때로 마스터로 재배치됩니다.

이미 제공된 일반적인 답변 - 사용git push -f origin myNewFeature재조정된 변경사항을 푸시할 때는 시작하는 것이 좋습니다.저는 당신의 작업 흐름을 방해할지에 대한 편집을 다루기 위해 이 답변을 씁니다.

우리가 당신이 사용할 것이라고 가정한다면.git pull --rebase ...(또는 이에 대한 일부 변형) 다음에 원격 분기로 강제 이동하면, 예제에서 워크플로우를 깨는 것은 developer2가 병합된다는 것입니다.myNewFeature안으로hisNewFeature다른 사용자가 분기에서 작업하지 않는 한 고유한 피쳐 분기의 기본을 변경할 수 있으므로 분기 영역을 구분하는 규칙이 필요합니다.

a) 병합만 하는 규칙을 설정하여 이 문제를 해결할 수 있습니다.master또는 b) 집합 만들기develop자신의 기반이 되는 가지.myNewFeature분기 및 병합만 수행하는 규칙 설정develop.master마일스톤 또는 릴리스(또는 설정하려는 경우)에만 예약됩니다.develop각 피쳐가 다른 피쳐 분기에 통합될 준비가 되면 해당 피쳐를 밀어넣을 수 있습니다.

저는 이것이 Gitflow 워크플로우의 단순화된 버전이라고 생각합니다.

저는 Cholo씨의 의견에 동의합니다. 그리고 아마도 Trevor Norris는 그것의 좋은 답변을 대체하기 위해 업데이트하는 것을 고려할 수 있을 것입니다.

git push -f origin devel0

와 함께

git push --force-with-lease origin devel0

이 스레드가 이 구글 검색에 대한 유일한 결과이기 때문에 나는 이 명령어를 정신없이 스크롤하는 사람들을 위해 다른 것들 중 하나일 뿐입니다.

git reset --soft HEAD~1

변경 내용을 커밋하지 않으면 파일이 수정되지 않습니다. 파일을 실행하면 편집된 것처럼 다시 표시됩니다.git status

언급URL : https://stackoverflow.com/questions/15143042/cant-push-to-branch-after-rebase