On the other hand, restoring changes made to the Working Tree would ultimately discard them completely. Performing restore on the staged changes would only undo what's about to be committed and not infer any loss of data, as the change itself is also present in the Working Tree (notice the "bar" line in index.js). Take a look at the below example illustrating a dirty Working Tree including changes staged for commit.
#RESET FILE TO MASTER GIT UPDATE#
And just like the official documentation states, restore doesn't update your branch (i.e. If, and when, that happens, restore is your weapon of choice.Īlthough restore has a multitude of use cases, in its simplest form it's used to remove changes from the Staging Area, or to discard changes made to your Working Tree. Not doing so might cause you to add files by accident which you don't want to commit. isn't something I'd recommend doing, as it's generally better to be more selective in what files to stage. ➕ Removing an accidentally staged file (restore) With the general command description from above top of mind, let's see how they differ in reality. Ok, still not crystal clear? Let's contextualize the above statements and solve our initial problems using them.
#RESET FILE TO MASTER GIT CODE#
In Git, there are three commands with similar names: reset, restore, and revert all which can be used to undo changes to your source code and history, but in different ways!įrom the official documentation the options are described like this: But let's look at how the above issues can be solved using reset, revert, and restore, starting with a quick glimpse at how the official documentation describes the commands. 🐛 Discovering a bug in a commit done way back (only noticing that the minor change to your project's config file caused ripple effects much later?)Īs with any development practice, problems like these can be solved in different ways using different techniques. 🌴 Accidentally making multiple commits on the wrong branch (on a streak, plowing ahead, thinking you're working in a topic branch when in fact you're still on master? – been there, done that!) all files in one go to save time, not realising you didn't want to stage that server log or binary?) ➕ Unintentionally adding files to the Staging Area (thought you could just $ git add. Below are three pretty common cases you've probably encountered yourself if you've been developing for a while. Sometimes this leads to errors being persisted in your Git history by accident, which then need to be corrected (no one wants to look like a fool in the eyes of fellow peers, right?).
Whenever you get into a development flow, it's easy to unintentionally cut corners to keep the momentum going. 3 common reasons for undoing changes in Git In this post we'll look at three common reasons for wanting to undo changes in Git, and look at the specific commands reset, revert, and restore to decide what to use when. But considering Git's core concept of using immutable snapshots, undoing changes requires some thought-work and can feel daunting to begin with. I've said it before, and it's worth repeating: Git is undo on steroids! As a developer, wanting to undo changes already committed is commonplace during development.
6 min read Photo by Jose Antonio Gallego Vázquez / Unsplash.
0 kommentar(er)
