git push는 로컬 변경 사항이 있지만 최신 정보를 말합니다.

git push는 로컬 변경 사항이 있지만 최신 정보를 말합니다.

---

원격 gitosis 서버와 로컬 git 저장소가 있으며 코드를 크게 변경할 때마다 변경 사항을 해당 서버로 푸시합니다.

그러나 오늘 로컬 변경 사항이 있고 로컬 리포지토리에 커밋하더라도 git push origin master를 실행할 때 '모든 것이 최신 상태'라고 표시되지만 git clone 을 사용 하여 원격 서버에서 파일을 체크 아웃하면 최신 변경 사항이 포함되어 있지 않습니다. 그리고 master라는 하나의 지점과 origin이라는 하나의 원격 서버 만 있습니다.

추신 : 이것은 ls-remote를 실행할 때 git이 표시하는 것입니다. 도움이되는지 확실하지 않습니다.

$ git ls-remote origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/remotes/origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c        refs/tags/stage3

---

당신은 우연히 분리 된 헤드 로 작업하지 않을 것 입니까?

에서처럼 :

최근 커밋이 브랜치 헤드가 아님을 나타냅니다.

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

---

git checkout맨 페이지 (강조 광산)에 언급 된 바와 같이 :

브랜치 중 하나의 끝에없는 커밋 을 체크 아웃하는 것이 유용 할 때가 있습니다 .
가장 확실한 예는 다음과 같이 태그가 지정된 공식 릴리스 지점에서 커밋을 확인하는 것입니다.

$ git checkout v2.6.18

자식의 이전 버전이 가능하고 사용하며 임시 지점 생성을 요청하지 않았다 -b옵션을하지만, 버전 1.5.0에서 시작하여, 위의 명령은 당신을 분리 HEAD이 태그에 의해 명명 커밋에서 직접 지점을 현재의 지점에서과 ( v2.6.18에 위의 예).

이 상태에서 모든 자식 명령을 사용할 수 있습니다. 예를 들어 추가 이동을 위해
사용할 수 있습니다 git reset --hard $othercommit.
분리 된 HEAD 위에 변경 사항을 작성하고 새 커미트를 작성할 수 있습니다 .
를 사용하여 병합을 만들 수도 있습니다 git merge $othercommit.

HEAD가 분리되어있는 동안의 상태는 분기에 의해 기록되지 않습니다 (자연 스럽지만 분기가 없습니다).
이것이 의미하는 바는 기존 분기 (예 :)로 전환하여 임시 커밋 및 병합을 버리고git checkout master 나중에 git prune또는 git gc가비지 수집 할 수 있다는 것입니다.
실수로이 작업을 수행 한 경우 예를 들어 HEAD에 대한 리플 로그를 요청할 수 있습니다. 예 :

$ git log -g -2 HEAD

---

Err.. If you are a git noob are you sure you have git commit before git push? I made this mistake the first time!

---

Maybe you're pushing a new local branch?

A new local branch must be pushed explicitly:

git push origin your-new-branch-name

Just one of those things about git... You clone a repo, make a branch, commit some changes, push... "Everything is up to date". I understand why it happens, but this workflow is extremely unfriendly to newcomers.

---

My issue was that my local branch had a different name than the remote branch. I was able to push by doing the following:

$ git push origin local-branch-name:remote-branch-name

(Credit to https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/)

---

Another situation that is important to be aware of: The sort of default state for git is that you are working in the "master" branch. And for a lot of situations, you'll just hang out in that as your main working branch (although some people get fancy and do other things).

Anyway, that's just one branch. So a situation I might get into is:

My active branch is actually NOT the master branch. ... But I habitually do the command: git push (and I had previously done git push origin master, so it's a shortcut for THAT).

So I'm habitually pushing the master branch to the shared repo ... which is probably a good clean thing, in my case ...

But I have forgotten that the changes I have been working on are not yet IN the master branch !!!

So therefore everytime I try git push, and I see "Everything up to date", I want to scream, but of course, it is not git's fault! It's mine.

So instead, I merge my branch into master, and then do push, and everything is happy again.

---

$ git push origin local_branch:remote_branch

Explanation

I had the same error & spent hours trying to figure it out. Finally I found it. What I didn't know is that pushing like this git push origin branch-x will try to search for branch-x locally then push to remote branch-x.

In my case, I had two remote urls. I did a checkout from branch-x to branch-y when trying to push from y locally to x remote I had the message everything is up to date which is normal cause I was pushing to x of the second remote.

Long story short to not fall in this kind of trap you need to specify the source ref and the target ref:

$ git push origin local_branch:remote_branch

---

See VonC's answer above - I needed an extra step:

$ git log -1
- note the SHA-1 of latest commit
$ git checkout master
- reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

I did this, but when I then tried to git push remoterepo master, it said "error: failed to push some refs. To prevent you from losing history, non-fast-forward updates were rejected, Merge the remote changes (e.g. 'git pull') before pushing again."

So I did 'git pull remoterepo master', and it found a conflict. I did git reset --hard <commit-id> again, copied the conflicted files to a backup folder, did git pull remoterepo master again, copied the conflicted files back into my project, did git commit, then git push remoterepo master, and this time it worked.

Git stopped saying 'everything is up to date' - and it stopped complaining about 'fast forwards'.

---

I have faced a similar situation; when I made the changes and tried to git push origin master, it was saying everything was up to date.

I had to git add the changed file and then git push origin master. It started working from then on.

---

From your git status, you probably has a different situation from mine.

But anyway, here is what happened to me.. I encountered the following error:

fatal: The remote end hung up unexpectedly
Everything up-to-date

The more informative message here is that the remote hung up. Turned out it is due to exceeding the http post buffer size. The solution is to increase it with

git config http.postBuffer 524288000

---

I had this problem today and it didn't have anything to do with any of the other answers. Here's what I did and how I fixed it:

A repository of mine recently moved, but I had a local copy. I branched off of my local "master" branch and made some changes--and then I remembered that the repository had moved. I used git remote set-url origin https://<my_new_repository_url> to set the new URL but when I pushed it would just say "Everything up to date" instead of pushing my new branch to master.

I ended up solving it by rebasing onto origin/master and then pushing with explicit branch names, like this:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

I hope this helps anyone who had my same problem!

---

Super rare - but still: On Windows, it might be that packed-refs has a branch with one letter case (i.e dev/mybranch), while refs folder has another case (i.e Dev/mybranch) when core.ignorecase is set to true.

The solution is to manually delete the relevant row from packed-refs. Didn't find a cleaner solution.

---

I ran into this myself when I merged a branch on Github and continued to develop in it locally. My fix was a little different than the others that have been suggested.

First I branched a new local branch off my old local branch (that I couldn't push). Then I pushed the new local branch to the origin server (Github). I.e.

$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch

This got the changes to show up on Github, albeit in newlocalbranch rather than oldlocalbranch.

---

In my case I had 2 remote repos.

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:git@bitbucket.org:...
origin  ssh:git@bitbucket.org:...

Both repo was same. Just one was https other was ssh. So removing the unwanted one, (In my case ssh. since I used https because ssh wasn't working!) fixed the issue for me.

---

My mistake was different than everything so far mentioned. If you have no idea why you would have a detached head, then you probably don't. I was working on autopilot with git commit and git push, and hadn't read the output from git commit. Turns out, it was an error message because I forgot -am.

[colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git.
[colin] ~/github/rentap.js [master] M % git push
Enter passphrase for key '/home/colin/.ssh/id_ecdsa': 
Everything up-to-date

Fixed it by putting -am where I usually do:

[colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'

---

Verify you haven't goofed your remote URL.

I just wanted to also mention that I ran into this after enabling Git as a CVS in a local Jenkins build configuration. It appears that Jenkins checked out the most recent commit of the branch I gave it and also reset my remote to correspond to the paths I gave it to the repo. Had to checkout my feature branch again and fix my origin remote url with 'git remote set-url'. Don't go pointing a build tool to your working directory or you'll have a bad time. My remote was set to a file path to my working directory, so it naturally reported everything up-to-date when I attempted to push changes with the same source and destination.

---

Another possibility is that you named a directory in your .gitignore file that got excluded. So the new commits wouldn't be pushed. It happened to me that I named a directory to ignore "search", but that was also a directory in my source tree.

---

There is a quick way I found. Go to your .git folder, open the HEAD file and change whatever branch you were on back to master. E.g. ref: refs/heads/master

---

I had the same issue. In my case it was caused by having to names for the same remote. It created the standard 'origin', but I've been using 'github' as my remote for a long time, so that was there too. As soon as I removed the 'origin' remote, the error went away.

---

I had this happen (commits in my git log were not on GitHub even though git said everything was up to date) and I'm confident the problem was Github. I didn't get any error messages in git, but GitHub had status errors and my commits were there several hours later.

https://status.github.com/messages

The GitHub status messages were:

• We are investigating reports of service unavailability.
• We're investigating problems accessing GitHub.com.
• We're failing over a data storage system in order to restore access to GitHub.com.

---

Another very simple yet noobish mistake of mine: I simply forgot to add a message -m modifier in my commit. So I wrote:

git commit 'My message'

Instead of correct:

git commit -m 'My message'

NOTE: It does NOT throw any errors! But you will not be able to push your commits and always get Everything up to date instead

참고 URL : https://stackoverflow.com/questions/999907/git-push-says-everything-up-to-date-even-though-i-have-local-changes