Now, let’s run the reset command with the mixed option: Visually, here’s the current state of our project: We expect our modified file file1.txt along with our new file file3.txt to be in the Staging Area, while one of our previous files, file2.txt, is still in the Working Directory. Let’s check the status of our project now: The rest of our project remains unchanged (remember, one of our files, file2.txt, is still in the Working Directory). To summarize, we added a new file in our project and updated the contents of one of our previous files. We’ll also modify the contents of our file file1.txt, which was sitting in the Commit History:Īnd add these changes to the Staging Area: Let’s add another text file with some content: Previously, we were at the following state: You can explicitly pass the -mixed flag to the reset command, but if you don’t, Git assumes that you’re performing a mixed reset, as it’s the default reset option. However, you can pass three arguments to the above command, depending on how you want it to update the state of your trees. The reset command in its raw form looks like this: When you tell Git to undo your committed changes, it updates the HEAD pointer as well as the state of the trees described in the previous section. The HEAD pointer always points to the last commit you made on your currently checked-out branch. When you commit your changes, Git uses a pointer called HEAD to maintain the latest commit of your project. The state of your project now looks like this: How Does Git Undo Your Changes? The above command moves your changes in file1.txt to the Commit History. It also gives you a unique commit id ( 5607c8b in this case) corresponding to that commit. Once you execute the above command, Git tells you the commit message, your current branch where you committed your changes, and the number of insertions and deletions pertaining to those changes. Consequently, you can also commit them to a remote repository. Once you move your changes to the Staging Area, you can confirm them by committing them locally. The Commit History contains a snapshot of all your work as commits. The state of our project now becomes: The Commit History Our second file, file2.txt, still remains in the Working Directory. Git highlights file1.txt in green, indicating that it’s inside our Staging Area. command to move all your changes to the Staging Area. Let’s add one of our files ( file1.txt) to the Staging Area using the following command: We can use the add command here to tell Git which files it needs to track for commits. Here’s a visual representation of the current state of our project: The Staging AreaĪfter you make changes in your Working Directory, you move them to a pre-commit area to tell Git that your changes are ready to be committed. Git marks them as “Untracked files,” highlighting them in red and representing them as changes in your Working Directory. Our Working Directory consists of two text files, each having the word “Hello” inside it. Next, let’s check the status of our project by running: $ echo hello>file1.txt $ echo hello>file2.txt Let’s create two simple text files inside our directory with some text inside them: This Working Directory represents the current state of your project on your code editor. Git manages and tracks the state of our project using three trees: the Working Directory, the Staging Area or Staging Index, and the Commit History. $ mkdir git-reset-examples & cd git-reset-examples & git init Create a new directory and initialize an empty Git repository inside it: To clearly understand how git reset works, let’s do a quick refresher on Git’s internal state management. I’ll walk you through some use cases of the reset command and different ways you can implement it, along with a few examples. It can be a tad bit tricky to grasp, so I’ll demystify some underlying concepts for you in this post. You can use Git to travel back in time and safely undo your changes in a project through a command called git reset. Git may indeed dominate version control today, but it has a popular feature that many developers still don’t fully understand. When it comes to version control systems in software development, Git is the most widely used- by far.
0 Comments
Leave a Reply. |