git push says "everything up-to-date" even though I have local changes

Are you working with a detached head by any chance?

As in:

indicating that your latest commit is not a branch head.

Warning: the following does a git reset --hard: make sure to use git stash first if you want to save your currently modified files.

$ 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>

As mentioned in the git checkout man page (emphasis mine):

It is sometimes useful to be able to checkout a commit that is not at the tip of one of your branches.
The most obvious example is to check out the commit at a tagged official release point, like this:

$ git checkout v2.6.18

Earlier versions of git did not allow this and asked you to create a temporary branch using the -b option, but starting from version 1.5.0, the above command detaches your HEAD from the current branch and directly points at the commit named by the tag (v2.6.18 in the example above).

You can use all git commands while in this state.
You can use git reset --hard $othercommit to further move around, for example.
You can make changes and create a new commit on top of a detached HEAD.
You can even create a merge by using git merge $othercommit.

The state you are in while your HEAD is detached is not recorded by any branch (which is natural --- you are not on any branch).
What this means is that you can discard your temporary commits and merges by switching back to an existing branch (e.g. git checkout master), and a later git prune or git gc would garbage-collect them.
If you did this by mistake, you can ask the reflog for HEAD where you were, e.g.

$ git log -g -2 HEAD

While git push says "everything up-to-date", you still can technically push a detached HEAD, as noted in the comments by Jonathan Benn

 git push origin HEAD:main

You have to specify the destination branch, since the source is not a branch, and does not have an upstream target branch.

I have faced same issue. As I didn't add changes to staging area. And I directly tried to push the code to remote repo using command :

git push origin master

And it shows the message Everything up-to-date.

to fix this this issue, try these steps

1. git add .
2. git commit -m "Bug Fixed"
3. git push -u origin master

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

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.

I had a situation where I was on a feature branch and my coworker created his own feature branch as well. I ran git fetch -a and then git push origin <coworkers_branch>. This kept telling me that everything was up to date.

I fixed it by checking out into <coworkers_branch> and then pulling from my feature branch, and then committing and pushing back to <coworkers_branch>.

I honestly hope this helps someone, because I spent much more time than I should have with this.

git branch -M <desired branch>

This did the trick 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'

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.

here, my solution is different from the above. i haven't figured out how this problem happen, but i fixed it. a little unexpectedly.

now comes way:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

the command that works for me is

$git push origin HEAD:use_local_cache

（hope you guys get out of this trouble as soon as possible)

I had multiple remotes. All but one pushed correctly, so I knew I didn't have a detached HEAD or commit issues.

Instead, I had accidentally given two remotes the same URL. The remote with the duplicated URL failed because I was pushing to a URL that had already been pushed to!

Using git remote -v showed my list of remotes and their URLs, where I realized the issue.

Resetting the failing remote to its correct URL fixed the issue:
git remote set-url <remote-name> <correct-url>

Another possibility is that you have commits that don't affect the directory you're pushing. So in my case I had a structure like

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

And I made a commit to master modifying README.md, then ran git subtree push --prefix client heroku-client master and got the message Everything up-to-date

I was working with Jupyter-Notebook when I encountered this deceptive error.

I wasn't able to resolve through the solutions provided above as I neither had a detached head nor did I have different names for my local and remote repo.

But what I did have was my file sizes were slightly greater than 1MB and the largest was almost ~2MB.

I reduced the file size of each of the file using How can I reduce the file size of my iPython notebook? technique.

It helped reduce my file size by clearing the outputs. I was able to push the code, henceforth as it brought my file size in KBs.

We need to add the files and commit the already changed/added files execute below commands

git add . or git add nameoffile #it will add the existing files in the project

git commit -m "first commit" #commiting all the files in the project

git push origin master

In my case, the cause of the trouble was that I was performing the git push/pull commands from a symlink folder in git bash! I was in a symlink folder inside a git project pointing to another git project, and the git pull/push commands were answering Everything up-to-date. When I moved (cd) to the actual folder's path (not through the symlink), git push/pull commands worked.