![]() Assuming we have three commits but the bad commit is the second commit. Now let's take a look at a more difficult example. This method would not have the disadvantage of git reset, it would point HEAD to newly created reverting commit and it is ok to directly push the changes to remote without using the -f option. But what if there are lots of commits to revert? We can revert a range indeed. In above example, we have only two commits to revert, so we can revert one by one. The HEAD will point to the new reverting commit.įor the example of git reset above, what we need to do is just reverting commit D and then reverting commit C. The use of git revert is to create a new commit which reverts a previous commit. Because of this, many companies forbid to use this method to rollback changes. In case one day we found that some of the commits ate good ones and want to keep them, it is too late. The drawback of this method is that all the commits after HEAD will be gone once the reset is done. git reset -hard a0fvf8Īfter executing above command, the HEAD will point to commit B.īut now the remote origin still has HEAD point to commit D, if we directly use git push to push the changes, it will not update the remote repo, we need to add a -f option to force pushing the changes. Currently HEAD is pointing to commit D 5lk4er, we just need to point HEAD to commit B a0fvf8 to achieve what we want. Now we want to rollback to commit B and drop commit C and D. What are their differences and corresponding use cases? We will discuss them in detail below.Ĭommit A and B are working commits, but commit C and D are bad commits. ![]() In this post, we will introduce two major ones used frequently by developers. In this case, rookie developers would be very nervous because they may get lost on what they should do to rollback their changes without affecting others, but to veteran developers, this is their routine work and they can show you different ways of doing that. When maintaining code using version control systems such as git, it is unavoidable that we need to rollback some wrong commits either due to bugs or temp code revert. Not entirely sure how this situation occurred, though a couple dozen developers plus IT changes may had something to do with it.īefore using reset think about using revert so you can always go back. So what I ended up doing by tracing through the post-receive hook and finding this, was having to go to the remote repository on the server, and there was the change (which wasn't on my local repository, which, in fact, said that it matched, no changes, nothing to commit, up to date, etc.) So while on the local, there were no changes, on the server, I then did a git checkout - some/file.ext and then the local and remote repositories actually matched and I could continue to work, and deploy. What was happening was (I think, not 100% positive) the git post receive hook was starting to run and screwing up due to movement changes in the remote server repository, which in theory, shouldn't have been touched. Remote: error: Your local changes to the following files would be overwritten by merge: Please, commit your changes or stash them before you can merge. So the situation that I ran into was the following:Įrror: Your local changes to the following files would be overwritten by merge: Related: How do I force "git pull" to overwrite local files? Or your file system doesn't support permissions, so you've to disable filemode in your git config. gitattributes) so it's better to commit what it says. If above won't help, it may be rules in your git normalization file (. If you don't care about your local changes, try to reset it to HEAD (original state), e.g. If you don't care about your local changes, you can switch to other branch temporary (with force), and switch it back, e.g. Do not use this option unless you have read git-rebase(1) carefully. It rewrites history, which does not bode well when you published that history already. This is a potentially dangerous mode of operation. This is equivalent to: checkout master, fetch and rebase origin/master git commands. So it'll apply your current branch on top of the upstream branch after fetching. You can try one of the following methods: rebaseįor simple changes try rebasing on top of it while pulling the changes, e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |