How can I change the git post of my 1 push to github?
My environment:
I am working with a team on a private github repository.
We only have a master branch.
To reproduce the problem:
-
I made a change (I'm talking about one thing, not muilticase) and add commit + push to the private github repository.
-
I saw a post on github after my push - and I have an error that I want to change.
-
How can I change the message of my push?
Edit: It is important for me that no history is left from my erroneous message.
Edit2: The files have already pushed them to the github repository and not just my local repository
source to share
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 machine with your changes.
HOWEVER
Chances are, you're better off just hitting the 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
This will allow you to easily edit the last post (content or commit message).
Then you find that you cannot press the remote, when you try it, it will be rejected with a warning like this:
! [rejected] master -> master (non-fast-forward) error: failed to push some refs to ' git@github.com : xxx / xxx.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (eg 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
This gives you two options:
- Pull first before pushing again
- Force-push (
git push -f
)
If you pull first - you put the unreleased commit back in your history, it will still exist, but you won't have any problems pushing to your remote branch. The initial commit will appear as a merge in history.
If you force-push, you literally force the remote branch to take over your local history and overwrite the history of the remote branches.
A note from git's own help is perhaps best used to describe why a force-push is usually bad:
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 verification. This can cause the remote repository to lose commits ; use it with care.
In context, "lost commits" will be the old version of the command you edited, but it can also include the changes that a colleague pushes between your first push and the force push. For this reason, this is a risky maneuver.
If you need to, it can be done - but either act quickly (so that no one downloads the borked-commit), or you don't know you would cause problems for any other developer pulling and pushing to this branch.
source to share
If no one has yet received the bad message, you can reset the HEAD pointer to the state before the commit was made:
git reset --soft HEAD^
This will undo your last commit and put the files in that commit as delivered, and you can commit the new message again. Note that you must push with --force as you are actually rewriting history on the server:
git commit -m 'new and correct message goes here'
git push --force origin master
source to share