![]() Ok, still not crystal clear? Let's contextualize the above statements and solve our initial problems using them. ![]() " revert is about making a new commit that reverts the changes made by other commits.".The command can also be used to restore files in the index from another commit." This command does not update your branch. " restore is about restoring files in the working tree from either the index or another commit.This operation changes the commit history." " reset is about updating your branch, moving the tip in order to add or remove commits from the branch.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.The obvious case is when you make some changes, commit them, then later decide you don’t want them anymore. But the state of your file will determine what changes you’re actually undoing. You may think of resetting a file as undoing changes. A file can have different contents in each of these locations. ![]() When you’re in the process of gathering changes, you stage files. ![]() Files that you commit ultimately end up in the repository. The files you edit locally belong to the working tree. The following terms are key to understanding the difference: working tree, staging area, and repository. On other occasions, you might want to roll back changes that you've already committed to the repository. Sometimes, you’ll want to undo local changes so a file is back in sync with the current repository. Also, the git reset command might not match your expectations for what resetting means. It’s important to note that resetting a file might mean different things to different people under different circumstances.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |