How can I change the git message of my 1 push in github?

Question

My Environment:

I am working with team on github private repository.

We have only master branch.

Reproduce the problem:

1. I made change (i talking about single and not muilticase) and add+commit+push to github private repository.

2. I saw the message in github after my push - and i have mistake that i want to change.

3. How can I change the message of my push?

Edit: Its important to me that no history will be left of my mistaken message.

Edit2: The files already pushed they are in github repository and not only in my local repository

Answer 1

TL;DR

git commit -v --amend
git push -f

This will allow you to edit the last commit message, and replace the commit on the remote with your edits.

HOWEVER

You are most likely better off simply pushing a correction.

The only way to change an existing commit is:

git add changed # example, add changed to the commit
git commit -v --amend # launch editor, edit commit message

That will allow you to easily edit your last commit (either contents, or commit message)

You'll then find you can't push to the remote, when you try it'll be rejected with a warning like this:

\n !  [rejected] master -> master (non-fast-forward) \nerror: failed to push some refs to 'git@github.com:xxx/xxx.git' \nTo prevent you from losing history, non-fast-forward updates were rejected \nMerge the remote changes (eg 'git pull') before pushing again.  See the \n'Note about fast-forwards' section of 'git push --help' for details. \n

Which gives you two options:

1. Pull first, before pushing again
2. Force-push ( git push -f )

If you pull first - you will put the un-edited commit back in your history, it'll still exist, but you'll have no problems pushing to your remote branch. The original commit will show up in the history as a merge.

If you force-push, you are literally forcing the remote branch to accept your local history and overwriting the remote branch's history.

The note from git's own help is perhaps best used to describe why forcing a push is generally a bad idea:

Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits ; use it with care.

In context, the "lost commits" will be the old version of the commit you edited - but it could also include changes a colleague pushes in-between your first push, and the forced-push. For this reason it's a risky manoeuvre.

If you need it it can be done - but either act quickly (so that nobody downloads the borked-commit) or know that you will cause problems for any other developer pulling and pushing to that branch.

Answer 2

If no one else has gotten the commit with the faulty message yet, you can reset your HEAD pointer to the state before you made the commit:

git reset --soft HEAD^

This will undo your last commit and put the files in that commit as staged and you can commit again with a new message. Note that you must push with --force since you are in fact overwriting history on the server:

git commit -m 'new and correct message goes here'
git push --force origin master