How to remove an updated file from a PR on GitHub
This is my third post about GitHub techniques that aren’t necessarily obvious to those of us who think in non-Git terminology. This post derives from the fact that I searched the internet for “remove file from PR” and was led astray by helpful people telling me how to use Git to delete a file.
Say you changed the content of a file by mistake, and to your surprise the file has become part of your set of changes tracked by Git, and has thus become part of your pull request (PR). Now you want to remove the file from the PR. You don’t want to delete the file itself, you just want to revert the inclusion of the file in the PR. (Because, if you delete the file, then that deletion becomes part of your change set, which is not what you want at all.)
The basic principle is: Undo the changes that you made to the file, to make the file disappear from the PR.
Assumptions:
- The instructions below assume that you have not yet merged the PR into the GitHub repository. If you have merged the PR, then you should revert the PR and create a new PR with just the updates you need.
- The instructions below assume that the unwanted updates are in a file that already exists in the GitHub repository. If the unwanted updates are in an entirely new file that you created, then you can delete the file from your file system, then run
git rm <file path>
followed bygit commit
to remove the file from the PR.
Note: Save your updates if you need them. If you still need the updates that you made to the file, perhaps to include in another PR, copy and save the updates somewhere outside your Git working area. You’ll lose the updates when you follow the steps described below.
Removing the updates manually
You can remove the updates manually, by copy-pasting the original contents of the file into your version of the file.
- Find the original version of the file, either on your fork if you forked from the main repository, or on the repository from which you cloned your local repository.
- Copy the entire content of the file and paste it into your copy of the file.
- Commit the new changes if necessary:
- If you had not yet committed your unwanted changes, then you don’t need to do any more.
- If you’d already committed your unwanted changes, create another commit now. The new commit wipes out your previous changes.
- If you’d already pushed the changes up to a remote repository, push the new commit now too.
Using git to remove the updates
Case 1: You haven’t yet committed the unwanted updates to your local repository.
Run the following command if you want to undo the updates in your working directory and you haven’t yet committed the unwanted updates:
git restore <file-name-including-path>
Case 2: You’ve committed the unwanted updates to your local repository but you haven’t yet pushed the unwanted updates to your remote repository.
By default, you have a remote repository named origin
, which is the repository from which you cloned your local copy of the files.
If you haven’t pushed the unwanted updates to the remote origin
repository, you can retrieve the file contents from the origin
repository.
The following sequence of commands assumes that the master
branch in the remote repository named origin
contains the unchanged version of the file. This is the case if you have not pushed your unwanted changes up to origin master
.
git fetch origin master git checkout origin/master -- <file-name-including-path> git commit -m "Reverted content of file."
Example of the checkout command:
git checkout origin/master -- docs/my-file.md
Case 3: You’ve already pushed the unwanted updates to your remote origin
repository.
In this case, you may be able to retrieve the file contents from your upstream
repository.
If you’re working on a fork of a repository, the convention is to give the name upstream
to the repository from which you forked. You can run the following command to see which remote repositories Git knows about:
git remote -v
Name the upstream repository now if you haven’t already named it. In the following example, replace <project>
with the GitHub project name and <repository>
with the repository name within the project:
git remote add upstream https://github.com/<project>/<repository>.git
Run the following commands to retrieve the file content from the upstream file:
git checkout upstream/master -- <file-name-including-path> git commit -m "Reverted content of file."
That’s all, folks
I’ve tried out all these commands myself, and they do what I expect them to do. Let me know if they do what you wanted to achieve too!
Here are my other two posts about Git and GitHub:
Posted on 21 March 2020, in GitHub and tagged Git, GitHub. Bookmark the permalink. 5 Comments.
Hi Sarah,
Thank you very much for these tips on how to work in GitHub. It is easy to go down the wrong path and getting back to the right place seems overly difficult. You’ve touched on several issues I’ve come up against and saved me a lot of time and frustration. I really appreciate it.
Hallo Garry
Thanks so much for your comment. I’m glad these tips are helpful. You’re right that it’s easy to go down the wrong path. It takes a long time to come to some sort of understanding of the Git philosophy, especially for those of us who use Git intermittently.
Cheers
Sarah
Hi Sarah BTW Great Post.
Somehow my PR is mixed up with other branch. because actually it is branched off from my local branches and not from the master. How do you remove commits in the PR that you don’t want and is it safe to delete these commits since they are already exist in other branch ?
Thank You Before
Hallo Denny
I haven’t worked on Git recently, so I can’t give you an answer from recent experience. I’ve done this procedure before. The trickiest part is identifying the commits that you want to remove.
This guidance looks good:
https://gist.github.com/silent1mezzo/1670623#remove_deep
It should be safe to delete the commits, since they exist in another branch. But to be extra safe, I’d make a copy of the working directory first.
Good luck!
Cheers
Sarah
and that is precisely why I despise git – simplest ( and I would argue extremely common ) problem requires an article and a 33 step solution ,instead of simple command built in. Big thank you to the author for exploring the issue and explaining it