수정 된 커밋을 원격 Git 저장소에 푸시하려면 어떻게해야합니까?
소스 코드로 약간 작업했을 때 평소와 같이 커밋 한 다음 원격 저장소로 푸시했습니다. 그러나 소스 코드에서 가져 오기를 구성하는 것을 잊었습니다. 그래서 이전 커밋을 바꾸기 위해 amend 명령을 수행합니다.
> git commit --amend
불행히도 커밋은 저장소로 다시 푸시 할 수 없습니다. 다음과 같이 거부됩니다.
> git push origin
To //my.remote.repo.com/stuff.git/
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to '//my.remote.repo.com/stuff.git/'
어떻게해야합니까? (원격 저장소에 액세스 할 수 있습니다.)
사실 한 번에 밀어 --force
및 .git
저장소와 리누스 꾸중있어 BIG TIME . 일반적으로 이것은 다른 사람들에게 많은 문제를 일으킬 것입니다. 간단한 대답은 "하지 마십시오"입니다.
어쨌든 다른 사람들이 그렇게하는 방법을 알려주는 것을 보았으므로 여기서 반복하지 않겠습니다. 그러나 여기 에 --force (또는 + master)를 사용하여 수정 된 커밋을 푸시 한 후 상황에서 복구 할 수있는 팁 이 있습니다.
git reflog
수정 한 이전 커밋을 찾는 데 사용 합니다 (라고 부르면 수정old
하여 만든 새 커밋을 호출합니다new
).old
와 사이에 병합을 생성하고 같은new
트리를 기록합니다 .new
git checkout new && git merge -s ours old
- 그것을 마스터에 병합하십시오.
git merge master
- 결과로 마스터 업데이트
git push . HEAD:master
- 결과를 밀어냅니다.
를 사용해서 개정하고 결과 병합 당신이 선호하는 것을 볼 수 있습니다 볼 수 푸시를 강제로 말소 커밋에 그런 불행한 충분히 있었다 사람들은 자신의 작품을 기반으로 한하는 new
동안 old
. 그들의 나중에 병합이 사이의 충돌이 표시되지 않습니다 old
그리고 new
그들이 고통을하지 않아도, 당신의 개정으로 인한 것을.
Git 안전 기능이 표시됩니다. Git은 브랜치의 헤드 커밋이 푸시하려는 브랜치의 현재 헤드 커밋의 직접적인 자손이 아니기 때문에 브랜치로 원격 브랜치를 업데이트하는 것을 거부합니다.
그렇지 않은 경우, 거의 동시에 동일한 저장소로 푸시하는 두 사람은 동시에 들어오는 새 커밋이 있다는 사실을 알지 못하며 마지막으로 푸시 한 사람은 다음 중 하나없이 이전 푸시의 작업을 잃게됩니다. 그들은 이것을 깨닫고 있습니다.
자신이 푸시하는 유일한 사람이고 수정 된 커밋을 푸시하거나 분기를 되 돌리는 커밋을 푸시하려는 경우 -f
스위치 를 사용하여 Git이 원격 분기를 업데이트하도록 '강제'할 수 있습니다 .
git push -f origin master
Git을 사용하면 원격 저장소가 구성 변수를 사용하여 먼 쪽에서 빠른 진행이 아닌 푸시를 거부 할 수 있으므로 이것이 작동하지 않을 수 있습니다 receive.denynonfastforwards
. 이 경우 거부 사유는 다음과 같습니다 ( '원격 거부'부분 참고).
! [remote rejected] master -> master (non-fast forward)
이 문제를 해결하려면 원격 저장소의 구성을 변경하거나 더러운 해킹으로 브랜치를 삭제하고 다시 만들 수 있습니다.
git push origin :master
git push origin master
일반적인 마지막 매개 변수에서 git push
사용하는 형식으로 <local_ref>:<remote_ref>
, local_ref
로컬 저장소에있는 지점의 이름이고 remote_ref
원격 저장소에있는 지점의 이름이다. 이 명령 쌍은 두 개의 속기를 사용합니다. :master
null local_ref가 있습니다. 즉, null 분기를 원격 측으로 푸시합니다 master
. 즉, 원격 분기를 삭제합니다. 없는 브랜치 이름 :
은 주어진 이름의 로컬 브랜치를 같은 이름의 원격 브랜치로 푸시하는 것을 의미합니다. master
이 상황에서는 master:master
.
빠른 폭언 : 아무도 여기에 간단한 답변을 게시하지 않았다는 사실은 Git CLI가 보여주는 절박한 사용자 적대감을 보여줍니다.
어쨌든, 이것을하기위한 "분명한"방법은, 당신이 밀기를 강요하려고하지 않았다고 가정하고, 먼저 당기는 것입니다. 이렇게하면 수정 한 (더 이상 가지고 있지 않은) 변경 사항을 가져 와서 다시 사용할 수 있습니다.
충돌이 해결되면 다시 푸시 할 수 있습니다.
그래서:
git pull
풀에서 오류가 발생하면 로컬 저장소 구성에 문제가있을 수 있습니다 (.git / config 분기 섹션에 잘못된 참조가 있음).
그리고 이후
git push
아마도 "비공개 병합"에 대해 말하는 주제와 함께 추가 커밋을 얻을 수 있습니다.
짧은 대답 : 수정 된 커밋을 공개 저장소에 푸시하지 마십시오.
Long answer: A few Git commands, like git commit --amend
and git rebase
, actually rewrite the history graph. This is fine as long as you haven't published your changes, but once you do, you really shouldn't be mucking around with the history, because if someone already got your changes, then when they try to pull again, it might fail. Instead of amending a commit, you should just make a new commit with the changes.
However, if you really, really want to push an amended commit, you can do so like this:
$ git push origin +master:master
The leading +
sign will force the push to occur, even if it doesn't result in a "fast-forward" commit. (A fast-forward commit occurs when the changes you are pushing are a direct descendant of the changes already in the public repo.)
Here is a very simple and clean way to push your changes after you have already made a commit --amend
:
git reset --soft HEAD^
git stash
git push -f origin master
git stash pop
git commit -a
git push origin master
Which does the following:
- Reset branch head to parent commit.
- Stash this last commit.
- Force push to remote. The remote now doesn't have the last commit.
- Pop your stash.
- Commit cleanly.
- Push to remote.
Remember to change "origin" and "master" if applying this to a different branch or remote.
I have solved it by discarding my local amended commit and adding the new changes on top:
# Rewind to commit before conflicting
git reset --soft HEAD~1
# Pull the remote version
git pull
# Add the new commit on top
git add ...
git commit
git push
I had the same problem.
- Accidentally amended the last commit that was already pushed
- Done a lot of changes locally, committed some five times
- Tried to push, got an error, panicked, merged remote, got a lot of not-my-files, pushed, failed, etc.
As a Git-newbie, I thought it was complete FUBAR.
Solution: Somewhat like @bara suggested + created a local backup branch
# Rewind to commit just before the pushed-and-amended one.
# Replace <hash> with the needed hash.
# --soft means: leave all the changes there, so nothing is lost.
git reset --soft <hash>
# Create new branch, just for a backup, still having all changes in it.
# The branch was feature/1234, new one - feature/1234-gone-bad
git checkout -b feature/1234-gone-bad
# Commit all the changes (all the mess) not to lose it & not to carry around
git commit -a -m "feature/1234 backup"
# Switch back to the original branch
git checkout feature/1234
# Pull the from remote (named 'origin'), thus 'repairing' our main problem
git pull origin/feature/1234
# Now you have a clean-and-non-diverged branch and a backup of the local changes.
# Check the needed files from the backup branch
git checkout feature/1234-gone-bad -- the/path/to/file.php
Maybe it's not a fast and clean solution, and I lost my history (1 commit instead of 5), but it saved a day's work.
If you have not pushed the code to your remote branch (GitHub/Bitbucket) you can change the commit message on the command line as below.
git commit --amend -m "Your new message"
If you're working on a specific branch, do this:
git commit --amend -m "BRANCH-NAME: new message"
If you've already pushed the code with a wrong message then you need to be careful when changing the message. i.e after you change the commit message and try pushing it again you end up with having issues. To make it smooth follow the following steps.
Please read the entire answer before doing it
git commit --amend -m "BRANCH-NAME : your new message"
git push -f origin BRANCH-NAME # Not a best practice. Read below why?
Important note: When you use the force push directly you might end up with code issues that other developers are working on the same branch. So to avoid those conflicts you need to pull the code from your branch before making the force push:
git commit --amend -m "BRANCH-NAME : your new message"
git pull origin BRANCH-NAME
git push -f origin BRANCH-NAME
This is the best practice when changing the commit message, if it was already pushed.
If you know nobody has pulled your un-amended commit, use the --force-with-lease
option of git push
.
In TortoiseGit, you can do the same thing under "Push..." options "Force: May discard" and checking "known changes".
Force (May discard known changes) allows the remote repository to accept a safer non-fast-forward push. This can cause the remote repository to lose commits; use it with care. This can prevent from losing unknown changes from other people on the remote. It checks if the server branch points to the same commit as the remote-tracking branch (known changes). If yes, a force push will be performed. Otherwise it will be rejected. Since git does not have remote-tracking tags, tags cannot be overwritten using this option.
You are getting this error because the Git remote already has these commit files. You have to force push the branch for this to work:
git push -f origin branch_name
Also make sure you pull the code from remote as someone else on your team might have pushed to the same branch.
git pull origin branch_name
This is one of the cases where we have to force push the commit to remote.
Here is a very simple and clean way to push your changes after you have already made a git add "your files"
and git commit --amend
:
git push origin master -f
or:
git push origin master --force
I had to fix this problem with pulling from the remote repo and deal with the merge conflicts that arose, commit and then push. But I feel like there is a better way.
I just kept doing what Git told me to do. So:
- Can't push because of amended commit.
- I do a pull as suggested.
- Merge fails. so I fix it manually.
- Create a new commit (labeled "merge") and push it.
- It seems to work!
Note: The amended commit was the latest one.
Here, How I fixed an edit in a previous commit:
- Save your work so far.
- Stash your changes away for now if made:
git stash
Now your working copy is clean at the state of your last commit. - Make the edits and fixes.
- Commit the changes in "amend" mode:
git commit --all --amend
Your editor will come up asking for a log message (by default, the old log message). Save and quit the editor when you're happy with it.
The new changes are added on to the old commit. See for yourself with
git log
andgit diff HEAD^
Re-apply your stashed changes, if made:
git stash apply
참고URL : https://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repository
'Program Tip' 카테고리의 다른 글
부트 스트래핑이란 무엇입니까? (0) | 2020.10.02 |
---|---|
C # 인터페이스. (0) | 2020.10.02 |
Swift 기반 애플리케이션은 OS X 10.9 / iOS 7 이하에서 작동합니까? (0) | 2020.10.02 |
Cygwin과 MinGW의 차이점은 무엇입니까? (0) | 2020.10.02 |
스택 추적이란 무엇이며 애플리케이션 오류를 디버그하는 데 어떻게 사용할 수 있습니까? (0) | 2020.10.02 |