This done with the standard commit command: In this case, the change is a revert of a single file. But once we revert the file, we need to commit that change. We didn't want a new commit for the file we reverted. I know what you're thinking, "Wait a minute, I thought the whole point was to not create a new commit?" Well that's half true. If I were going to revert the file in the screenshots above, that would look like this: The format of the git command will look like this: Once you've opened a terminal and changed to the working directory, you use git checkout to revert the file. Because of this, you only want the underlined portion.Īll that is left is to revert the file. The first directory listed is the working directory name, and will be the directory you're in when using this file path. Notice I only underlined part of the path.
This part is easy because the path to the file is on the same GitHub screen where you found the commit ID for the file.Ībove you can see the same screenshot from before, but this time I've underlined the file path. The next thing you need is the path to the file from the working directory.
Either write this commit ID down, or copy it to your clipboard. That is the commit ID for the most recent commit in which that file was modified. On the right hand side you can see a 7 digit commit ID and a date. Once you navigate to the file, right above the file you should see this: Reverting the file is a much cleaner what to handling it.įirst you need to go to the shared repository on GitHub and find the file that you want to revert. However, manually changing each line of code in those files back to their original state and doing a new commit can lead to a messy commit history. This need arises because you sometimes need to change files not related to you're pull request in order to test the feature you're working on.
Once you start collaborating with other developer it's going to be important to know how to revert a single file to a certain commit.