The only really tricky part here is "revert a merge".
#Rollback a commit git sourcetree how to#
See How to revert Git repository to a previous commit? and Rollback to an old Git commit in a public repo (specifically jthill's answer). It is possible to achieve revert to / restore, but the commands that do this are git checkout and git read-tree (both of these are mildly tricky, for different reasons). Remember that git revert really means back out a change, not revert to, i.e., restore, some particular version. In general the forced push is a bad practice, but keeping useless commits and reverts around is not nice as well, so another solution would be to actually create a new branch "staging2" and do your testing in that branch instead: git checkout staging
(the reset line retargets the local "staging" branch so that it points to a commit that is right before your top commit) If you want to really make it gone, so that nobody can blame you, you can do at your risk: git checkout staging it is an addition to the log, that's why the push will be clean. git revert actually doesn't delete your commit, but it creates a new commit on top, that undoes all the changes (if you added a file - the new commit will remove it, if you removed a line - the new commit will add it back etc.), i.e. After you do git checkout staging, you actually create a distinct local name that represents the remote branch.
Note: for the last commit in the log you would write git revert HEAD.Īnd then you update your remote "staging": git pushĮxplanation: In git if you have a remote you are dealing with 2 distinct repositories (local and remote). Then you first revert it locally in your local "staging" branch: git checkout staging
If you know that it's the last one, you can use a special identifier "HEAD". First you need to do a git log to find out which commit ID you want to revert.
0 kommentar(er)
