One caveat with rebase is that it will recreate all of the commits it rebases. I tend to also like to use interactive rebase a lot which gives you more flexibility allowing you to rename commits, reorder them, squash them into other commits, etc. There is a convenience option for this with git pull Rebasing master on origin/master turns this into master: A - B - D -C Rebase works when you've already commit your changes.
the remote), and replay your changes on top one-by-one your local changes), pull the other branch (e.g.
Rebase will compare two branches and will pop off the changes of your current branch (e.g. We can pull the fresh files from master: git checkout master - path/to/file.javaĪnd now a file is reset! And if you just want to reset part of a file, -patch should work the same way.Assuming you have already commit your changes then I would use rebase (unless you're still working on your changes, then you might want to keep them in your local copy). Creating a whole new branch was actually just an un-necessary step. You know you need to reset a few files, but you shouldn't need to reset the whole thing. Will open up a dialog that allows you to select the parts of the changes to the file you want to keep.įor some reason, you're just enamored with your feature branch and you're unwilling or unable to give it up. I suggest getting familiar with the -patch option on git checkout: git checkout -p feat-foo - path/to/file.java Let's say you have a file with some changes, and you only want to pull in some of those changes.
#DISCARD COMMIT GIT FREE#
Now you can feel free to delete that branch, and rename feat-foo-v2 to feat-foo. Do this a few more times, and the old branch will be obsolete. Now you have a copy of the individual file from the old branch. While in your root git directory: git checkout feat-foo - path/to/file/to/be/used.java But you likely still did a bunch of work that is still good, you just need to pull in those files. Git checkout -b feat-foo-v2 # make a second version of feat-foo branch When you have made dozens of commits and dozens of files changed and you need to reset git checkout master I'm going to show you how I start over on a branch in 2021: So, there's a number of legacy answers here. So in terms of clearing changes made from working on the wrong branch, stash gives you a lot of flexibility to recover from your boo-boo.Īnyhoo, if you want a reversible means of clearing changes to a branch, the foregoing is a less dangerous way in this use-case. I didn't really want to restore those changes, just wanted to validate I could get them back, so I cleared them again.Īnother option is to apply the stash to a different branch, rather than wipe the changes. First step is to find the hash of the stash I just cleared/dropped: git fsck -no-reflog | awk '/dangling commit/ 'Īfter learning the hash, I successfully restored the uncommitted changes with: git stash apply hash-of-cleared-stash Let's say I now wanted to restore those changes. All the changes made to the files in error to master were gone and parity restored. D'Oh! As my situation is hardly unique (we've all done it, haven't we ->), I'll offer a reversible way I used to discard all changes to get master looking like develop again.Īfter doing a git diff to see what files were modified and assess the scope of my error, I executed: git stashĪfter first stashing all the changes, they were next cleared. You guessed it: I started modifying a few files directly on master. I found this question after making a merge and forgetting to checkout develop immediately afterwards.
REVERSIBLE Method to Discard All Changes:
0 kommentar(er)
