질문자 :Spyros
원격이 아닌 "기본" 리포지토리를 설정하고 내 컴퓨터에 복제했습니다. 일부 로컬 변경을 수행하고 로컬 저장소를 업데이트하고 변경 사항을 원격 저장소로 다시 푸시했습니다. 그 시점까지는 상황이 괜찮았습니다.
이제 원격 저장소에서 무언가를 변경해야 했습니다. 그런 다음 로컬 저장소에서 무언가를 변경했습니다. 원격 저장소로의 변경이 필요하지 않다는 것을 깨달았습니다. git push 를 시도했지만 다음과 같은 오류가 발생했습니다.
기록 손실을 방지하기 위해 빨리 감기가 아닌 업데이트가 거부되었습니다. 다시 푸시하기 전에 원격 변경 사항을 병합하십시오. git push --help 의 '빨리 감기에 대한 참고 사항' 섹션을 참조하세요.
나는 그것이 아마
git push --force
내 로컬 복사본이 원격 복사본에 변경 사항을 푸시하고 동일하게 만듭니다. 업데이트를 강제 실행 하지만 원격 저장소로 돌아가 커밋을 수행하면 파일에 오래된 변경 사항(기본 원격 저장소가 이전에 있었던 것)이 포함되어 있음을 알 수 있습니다.
답변 중 하나 에 대한 의견에서 언급했듯이 :
[I] 강제로 시도했지만 변경 사항을 저장하기 위해 마스터 서버로 돌아갈 때 구식 스테이징이 됩니다. 따라서 커밋 할 때 리포지토리가 동일하지 않습니다. 그리고 git push를 다시 사용하려고 하면 동일한 오류가 발생합니다.
이 문제를 어떻게 해결할 수 있습니까?
그냥 해:
git push origin <your_branch_name> --force
또는 특정 저장소가 있는 경우:
git push https://git.... --force
이렇게 하면 이전 커밋이 삭제되고 현재 커밋이 푸시됩니다.
적절하지 않을 수도 있지만 누군가이 페이지를 우연히 발견하면 간단한 솔루션을 원할 것이라고 생각했습니다 ...
짧은 깃발
또한 -f 는 --force 약자이므로
git push origin <your_branch_name> -f
또한 작동합니다.
그리고 push --force 가 작동하지 않으면 push --delete 할 수 있습니다. 이 인스턴스의 두 번째 줄을 보십시오.
git reset --hard HEAD~3 # reset current branch to 3 commits ago git push origin master --delete # do a very very bad bad thing git push origin master # regular push
하지만 조심...
절대로 공개 git 기록으로 돌아가지 마십시오!
다시 말해:
- 공개 저장소를
force 푸시하지 마십시오. -
pull 수 있는 이것 또는 그 어떤 것도 하지 마십시오. - 누군가가 이미 가져온 저장소의 기록을
reset 하거나 rewrite 쓰지 마십시오.
물론 이 규칙에도 예외적으로 드문 예외가 있지만 대부분의 경우 그렇게 할 필요가 없으며 다른 모든 사람에게 문제를 일으킬 것입니다.
대신 되돌리기를 수행하십시오.
그리고 항상 공개 저장소에 푸시할 때 주의하십시오 . 되돌리기:
git revert -n HEAD~3..HEAD # prepare a new commit reverting last 3 commits git commit -m "sorry - revert last 3 commits because I was not careful" git push origin master # regular push
실제로 두 원본 HEAD( 되돌리기 및 악의 재설정에서 )에는 동일한 파일이 포함됩니다.
push --force 주위에 업데이트된 정보와 더 많은 인수를 추가하도록 편집
푸시 대신 임대로 강제 푸시를 고려하지만 여전히 되돌리기를 선호합니다.
push --force 가 가져올 수 있는 또 다른 문제는 당신이 하기 전에 누군가가 무언가를 푸시할 때, 그러나 당신이 이미 가져온 후에 있을 때입니다. 지금 리베이스 버전을 강제로 푸시 하면 다른 사람의 작업 이 대체됩니다.
git 1.8.5에 도입된 git push --force-with-lease ( 질문에 대한 @VonC 의견 덕분에 )는 이 특정 문제를 해결하려고 합니다. 기본적으로 최신 가져오기 이후 리모컨이 수정된 경우 오류가 발생하고 푸시하지 않습니다.
push --force 가 필요하지만 여전히 더 많은 문제를 방지하려는 경우에 좋습니다. push --force 동작이어야 한다고 말할 수 있습니다. 그러나 그것은 강제로 변명 인에서 멀리 아직도 push . rebase 전에 가져온 사람들은 여전히 많은 문제를 겪을 것이며, 대신 되돌리면 쉽게 피할 수 있습니다.
git --push 인스턴스에 대해 이야기하고 있기 때문에...
왜 누군가가 강제로 푸시를 원할까요?
@linquize 는 댓글에 대한 좋은 푸시 포스 예제를 가져왔습니다: 민감한 데이터 . 푸시하면 안 되는 데이터를 잘못 유출했습니다. 당신은 충분히 빨리 경우, 당신이 할 수있는 "수정" * 를 상단에 밀어 강제로.
* 데이터는 가비지 수집 을 수행하거나 어떻게든 청소 하지 않는 한 여전히 리모컨에 있습니다. 이미 가져온 다른 사람들에 의해 퍼질 가능성도 분명히 있지만 아이디어는 알 수 있습니다.
로컬 브랜치 A에 있고 로컬 브랜치 B를 원본 브랜치로 강제 푸시하려는 경우 CI는 다음 구문을 사용할 수 있습니다.
git push --force origin B:C
우선 "메인" 리포지토리에서 직접 변경하지 않을 것입니다. 정말로 "메인" 리포지토리를 갖고 싶다면 해당 리포지토리로 푸시만 하고 절대 직접 변경하지 마십시오.
발생하는 오류와 관련하여 로컬 저장소에서 git pull git push 를 시도했습니까? 당신이 현재 하고 있는 일은 (내가 그것을 잘 이해했다면) 강제로 푸시한 다음 "메인" 리포지토리에서 변경 사항을 잃는 것입니다. 변경 사항을 먼저 로컬로 병합해야 합니다.
다음 명령을 사용하십시오.
git push -f origin master
나는 정말로 추천할 것이다:
즉, 풀/풀할 단일 업스트림 리포지토리를 갖기 위해 주 서버와 로컬 컴퓨터 모두에서 베어 리포지토리에 액세스할 수 있도록 유지합니다.
이것은 기록을 유지하면서 기업 gitHub 저장소의 마스터를 교체하기 위한 우리의 솔루션이었습니다.
push -f to master on 기업 리포지토리는 분기 기록을 유지 관리하기 위해 비활성화되는 경우가 많습니다. 이 솔루션은 우리에게 효과적이었습니다.
git fetch desiredOrigin git checkout -b master desiredOrigin/master // get origin master
git checkout currentBranch // move to target branch git merge -s ours master // merge using ours over master // vim will open for the commit message git checkout master // move to master git merge currentBranch // merge resolved changes into master
귀하의 분기를 desiredOrigin 푸시하고 PR을 작성하십시오.
나는 같은 질문을했지만 마침내 알아 냈습니다. 가장 해야 할 일은 다음 두 가지 git 명령을 실행하는 것입니다(해시를 git 커밋 개정 번호로 대체).
git checkout <hash> git push -f HEAD:master
출처 : http:www.stackoverflow.com/questions/5509543/how-do-i-properly-force-a-git-push