현재 지점의 끝이 뒤에 있기 때문에 업데이트가 거부되었습니다.

나는 Git을 처음 사용하기 때문에 초보자처럼 나를 자유롭게 다루십시오.

우리의 작업 흐름은 이와 같습니다. 에 연락 할 수있는 지점 dev이 있습니다 origin/dev. 변경을 수행하면 dev에서 분기를 작성합니다.

자식 체크 아웃 -b FixForBug origin / dev

이제 나는 지점을 FixForBug추적하고 있습니다 (나는 그것이 올바른 단어라고 생각합니다) origin/dev. 따라서 내가 그렇게하면 git pull새로운 변화가 생길 것 origin/dev입니다. 이제 수정 작업이 끝나면 동일한 항목이라는 원격 지점으로 푸시합니다.

먼저 변경 사항을 풀고 origin/devrebase를 수행하십시오.

자식 풀-리베이스

그런 다음 변경 사항을 동일한 이름의 원격 지점으로 푸시합니다.

git push origin FixForBug

이제 원격 서버에 지점이 있으며 해당 변경 사항을 승인하고 개발 지점으로 다시 병합하기위한 풀 요청을 만들 수 있습니다. 나는하지 않는다 지금까지 아무것도 밀어 origin/dev자신. 나는 이것이 꽤 일반적인 워크 플로우라고 생각합니다.

내가 처음 할 때 git push잘 작동하고 원격 지점을 만듭니다. 그러나 두 번째로 밀어 넣으면 (코드 검토 중에 누군가가 문제를 지적하자) 다음과 같은 오류가 발생합니다.

오류 : 일부 참조 를 ' https://github.limeade.info/Limeade/product.git ' 으로 푸시하지 못했습니다. 힌트 : 현재 분기의 팁이 힌트 뒤에 있기 때문에 업데이트가 거부되었습니다. 다시 변경하기 전에 원격 변경 사항 (예 : 힌트 : 'git pull ...')을 통합하십시오. 힌트 : 자세한 내용은 'git push --help'에서 '앞으로 가기에 대한 참고 사항'을 참조하십시오.

그러나 내가 그렇게하면 1 커밋 ( git status앞의 origin/dev의미가 있음)으로 앞서고 힌트를 따르고 실행 git pull하면 모든 것이 최신 상태라고 말합니다. 내가 생각하는 내 상류 지점과 다른 지점에 밀어거야 때문입니다. 다음을 실행하여이 문제를 해결할 수 있습니다.

git push -f origin FixForBug

이 경우 변경 사항을 원격 지점으로 푸시하고 (강제 업데이트) 라고 말하면 모든 항목 이 원격 지점에서 양호 해 보입니다 .

내 질문 :

-f이 시나리오에서 왜 필요한가요? 일반적으로 무언가를 강요 할 때 , 잘못하거나 최소한 표준 관행에 어긋 났기 때문입니다. 이 작업을 수행해도 괜찮습니까? 아니면 원격 지점에서 무언가를 엉망으로 만들거나 결국 내 물건을 개발자로 병합 해야하는 사람을 위해 번거 로움을 만들 수 있습니까?

이 -f 되어 실제로 때문에 REBASE 요구. 리베이스를 수행 할 때마다 원격 브랜치를 커밋으로 빨리 전달할 수 없으므로 강제 푸시를 수행해야합니다. 푸시하기 전에 항상 당기기를 확인하고 싶지만 해당 문제에 대해 강제로 마스터 또는 개발자에게 푸시하지 않으려는 경우 푸시하려는 새 브랜치를 생성 한 다음 병합하거나 PR을 만들 수 있습니다 .

로컬 분기 FixForBug가 원격 분기 FixForBug보다 앞서 있지 않도록하려면 푸시하기 전에 변경 사항을 가져 와서 병합하십시오.

git pull origin FixForBug
git push origin FixForBug

를 사용하지 않으려면 -f그냥 사용할 수 있습니다.

git pull

대신에

git pull --rebase

비 REBASE은의 변경을 가져옵니다 origin/dev및 병합 당신으로 그들을 FixForBug지점. 그럼, 당신은 실행할 수 있습니다

git push origin FixForBug

를 사용하지 않고 -f.

the tip of your current branch is behind its remote counterpart로컬에없는 원격 지점에 변경 사항이 있음을 의미합니다. 그리고 git은 새로운 변경 사항을 가져 와서 REMOTE코드와 병합 한 다음 push원격으로 병합하도록 지시합니다 .

이 명령을 사용하여 로컬 저장소 ()를 사용하여 서버를 강제로 변경할 수 있습니다.

git push -f origin master

와 -f태그는 무시됩니다 Remote Brach code코드와 함께.

"현재 분기의 끝이 뒤에 있기 때문에 업데이트가 거부되었습니다"라는 메시지가 표시 될 때 Azure DevOps와 함께 사용한 명령은 다음과 같습니다.

자식 풀 원점 마스터

(또는 새 폴더로 시작하여 복제를 수행 할 수 있음) ..

이 답변은 제기 된 질문, 특히 Keif가 위의 답변에 답변하지 않았지만 질문의 제목 / 제목 텍스트에 답변하며 이는 Azure DevOps 사용자에게 일반적인 질문입니다.

나는 주석을 언급했다 : 위의 Keif의 답변에서 "항상 밀기 전에 잡아 당기고 싶다"고 언급했다.

또한 Git 명령 줄 도구 외에도 Git Gui 도구를 사용했습니다.

(Git Gui 내에서 명령 줄 명령 "git pull origin master"와 동등한 방법을 잘 모르겠으므로 명령 줄로 돌아갑니다.)

수행하려는 다양한 조치에 대한 다양한 git 명령을 표시하는 다이어그램은 다음과 같습니다.

이것은 나에게 일어난 일입니다.

• 어제 마스터에게 풀 요청을했습니다.
• 저의 동료가 오늘 그것을 검토 한 결과 마스터 지점과 동기화되지 않은 것을 확인했습니다.
• 나는 그가 그렇게 몰랐다.
• 그런 다음 master를 로컬로 병합하고 푸시하려고했지만 실패했습니다. 왜? 내 동료가 master와 병합하여 추가 커밋을 만들었으므로 로컬에는 없었습니다 !

솔루션 : 추가 커밋을 받으려면 내 브랜치를 내리 십시오 . 그런 다음 원격 지점으로 다시 밀어 넣으 십시오.

말 그대로 내 지점에서 한 일은 다음과 같습니다.

git pull
git push

이것이 내 문제를 해결 한 방법입니다

업스트림 브랜치가 분기되어 있고 오리진이 리포지토리이고 MR / PR을 업스트림 브랜치로 보내려고한다고 가정 해 봅시다.

당신은 이미 약 4 커밋에 대해 말했고 Updates were rejected because the tip of your current branch is behind.

여기 내가 한 일이 있습니다

먼저 4 개의 커밋을 모두 스쿼시하십시오.

git rebase -i HEAD~4

pick작성된 커밋 목록이 표시 됩니다. (편집기에서 열림)

예

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

에

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

그 후에는 결합 커밋을 저장할 수 있습니다

다음

커밋을 숨겨야합니다

방법은 다음과 같습니다

git reset --soft HEAD~1
git stash

이제 업스트림 지점으로 리베이스

git fetch upstream beta && git rebase upstream/beta

이제 막힌 커밋을 터트려

git stash pop

이 변화를 저지르고 밀어

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f

커밋이 현재 푸시보다 앞서야합니다.

1) 자식 풀 원점 "누르고 싶은 브랜치 이름"

2) 자식 리베이스

git rebase가 성공하면 좋습니다. 그렇지 않으면 모든 병합 충돌을 로컬로 해결하고 원격으로 리베이스 할 때까지 계속 유지하십시오.

3) git rebase-계속

Visual Studio Code를 통해 rebase를 푸시하려고 할 때이 문제가 발생했습니다 .git 출력 창에서 명령을 복사하고 Visual Studio Code의 터미널 창에서 명령을 실행하여 문제를 해결했습니다.

필자의 경우 명령은 다음과 같습니다.

git push origin NameOfMyBranch:NameOfMyBranch