I recently pushed a commit to GitHub that I shouldn't have, which could have contained sensitive information. Thankfully it didn't. I immediately deleted the file in question and quickly noticed that I and anyone with access to this repo can see the contents of the uploaded file if they click on the commit history and load diff. Is there any way to delete the contents of that commit so that it no longer shows up in my repository commit history?
GitHub documents the process quite clearly.
Basic steps:
Rebase your changes and remove the offending commit from your local history.
Force push the rebased changes to GitHub.
Contact support to have the offending commit purged from pull requests, caches and issues it might be linked to.
I find this missing feature in GitHub to be frustrating, so I'm documenting my work-around here to help the next person. Alternate, better work-arounds are welcome.
This question is not a duplicate of How to change the author of a commit in GitHub? ...because that question isn't clear if it is asking about how to rewrite the author of a few commits and the push those to github, or actually change the name under which the entire PR was created in the first place. And, the accepted answer to that question was a simple fix to the local .git/config file, which clearly will not solve the GitHub problem I'm talking about here.
At the top of a GitHub PR you'll see something like this:
username wants to merge 1 commit into base_branch from their_feature_branch
That username: how can we change that?
Example PR (chosen "at random" from GitHub, just to show the PR author line in the image below). Image:
Example use-cases:
The team-mate who opened this PR just left the company, and we'd like to commandeer (take over) and finish the PR for them.
Change of work-loads have necessitated you take over a partially-complete PR from another team-mate. How can you switch that PR to be in your name?
Assume that everyone has full push access to the whole repo, meaning that you can push/pull to/from each other's branches anyway.
Real-life example of why I want to know how to change the owner of an open PR
In 2020 a peer of mine opened a PR on a brand new branch that was intended to be worked on for 3 months until it had a ton of new features in it. Then, it would be merged. Peer reviews would occur on mini-PRs as they go into this separate, long-running, stand-alone branch.
The PR was initially opened with a "do not review" label, just to get the branch up so our CI (Continuous Integration) system would start to build it daily to ensure it wasn't broken. We would all then contribute to this branch with the understanding that the one person who opened it would be the "process owner" and walk the branch through all testing and processes until it gets merged back into the main branch.
My peer then left the company right after opening this PR. I immediately became the process owner and worked on the PR for 3 months and eventually merged it. That repo is set up by the maintainers to disable all types of merges except "squash merges" (see my comments under this question), so when it was merged, Github squashed all of the dozens of individual commits into one single huge commit and attached my peer's name (and keep in mind he hadn't been at the company for the last 3 months) to that commit, even though it was the commit that I had managed for nearly all of its 3 month lifetime.
git diff --shortstat 123456789abcd~..123456789abcd shows the following output:
164 files changed, 10360 insertions(+), 3013 deletions(-)
...meaning that commit had touched 164 files, added 10360 lines, and deleted 3013 lines. And guess what!? My peer's name is the name on all those changes, just because he opened the PR initially, instead of my name, even though a lot of that work was mine and I was the process owner of it. That's confusing, to say the least. I would have liked to have my name on all of those changed lines instead.
My answer here is therefore what I should have done, but didn't at the time, because I didn't know GitHub always uses the name of the person who opened the PR, and I didn't know how to change the owner of the PR. Now, I do know, and I have documented my workarounds in my answer.
What I actually did was option 1 from my answer, but what I should have done is option 2 from my answer.
Sometimes, an assignment gets passed off from one team member to another, or, a team member leaves a team. When this happens, it would be nice to "commandeer", or take over, their PR so that it becomes your PR. As far as I can tell, however, this isn't possible on GitHub yet.
On Phabricator (a paid alternative to GitHub, and originally an internal tool used at Facebook), this is as simple as clicking a button to "Commandeer Revision" (see old documentation here under "Take over another author's change"). This is known as "commandeering someone's diff", where "diff" here is the Phabricator-equivalent to a GitHub PR, or "Pull Request".
How to commandeer (take over) someone else's PR in GitHub
ie: how to change the owner of the open PR so it looks like you opened the PR, not them.
So, since GitHub doesn't allow commandeering a PR, here are some options:
Continue using their open PR, in which case their name, not yours, gets attached to the final, squashed-and-merged commit in the event you use the "Squash and merge" option to finish the PR. If they did the bulk of the work, that's fine. But, if you are taking over a PR and you are doing the bulk of the work, you'd probably like your name to be attached to the work. So, instead:
Just close their open PR and open your own.
To do option 1 above: just keep using their open PR, in which their name gets attached to the final, squashed merge commit:
Check out their branch locally
git fetch origin their_branch_name
git checkout their_branch_name
Optionally, rename your local copy of their branch to something you like
git branch -m new_branch_name
Set the upstream for this branch so that when you git push it will push to their remote branch name which is attached to their open PR:
git push --set-upstream origin new_branch_name:their_branch_name
Note: I learned the git push -u origin local_FROM_branch:remote_TO_branch syntax here: How can I push a local Git branch to a remote with a different name easily?
See also my own new answer to that question here.
Now, to push you can just call:
git push
And to pull from that branch, in case another team-mate pushes changes to it too, you can specify:
git pull origin their_branch_name
Now, whenever the PR is complete and reviewed, you can merge it via GitHub. If you choose the regular merge option you'll get credit for your commits. If you choose the "squash and merge" option, the original author, NOT you gets full credit for the entire merge. This is dumb and should be fixed by GitHub, but, that's how it is.
[My preference] Here's how to do option 2 above: just close their PR and open your own:
Go to the bottom of their PR and click "Close pull request": .
Check out their branch locally
git fetch origin their_branch_name
git checkout their_branch_name
Optionally, but recommended, rename your local copy of their branch to something you like.
git branch -m new_branch_name
Push this as a new branch to the remote origin on GitHub. This pushes to your remote branch and allows you to open a NEW PR under YOUR name on GitHub:
git push --set-upstream origin new_branch_name
# Note: if you didn't rename the branch to `new_branch_name` above,
# and it is therefore still called `their_branch_name` locally, just
# use `their_branch_name` here instead.
After pushing like that for the first time, GitHub will output a URL in the terminal where you pushed, which you can click on to open a new PR under your name. (If you don't have this feature, just go to Github.com and manually open up a PR there). Open a PR and voilá! It's now YOUR PR and you've just "commandeered" their PR!
Now, to push you can just call:
git push
And to pull from that branch, in case another team-mate pushes changes to it too, you can specify:
git pull origin new_branch_name
Now, when the PR is complete and reviewed, you can merge it on GitHub. If you choose the "squash and merge" option, your name will now be used for the final, single commit which gets merged to the base_branch.
See also:
How can I push a local Git branch to a remote with a different name easily?
[my own new answer I just added there] How can I push a local Git branch to a remote with a different name easily?
Just giving An example when this ability will be a necessary feature:
One of the PRs I Owned had state errors, that are not a part of the branch, but are localized to the PR:
>> git checkout -b new_name;
>> git push origin new_name;
>> opened new PR without errors.
The errors are not in GitHub per-se, but in some plugins and extensions we made for testing environment.
But I want the IT team to debug the state-corruption, so I would like to pass my PR onto them (the PR but not the code or the branch, obviously).
While there is loads of information available on how to revert to a specific commit using the git command line - e.g. How to revert Git repository to a previous commit?
Is there a way to achieve same using the github gui? There is a feature to revert the latest commit. However I was unable to find options from the Commits history to revert to a specific commit in the list:
on the right and here is what we see:
so there is no feature shown here for Revert to this commit.
Jump to the PR which is included in the commit which is to be reverted. Go to conversation section, there you will see revert option in front of all commits included in that PR (screenshot)
You can press the button on the side < > (like in your first picture) and with this you can browse the repository at the time after this commit. Now you can create a pull request or you can download the repository at this very point in time.
I guess there is no other solution if you really want to achieve this in the browser. In GitHub desktop there is the Revert button for each of your commits (screenshot).
Using gitHub (and Eclipse Egit, and SourceTree) with a forked repo, how can I make a pull request that just contains a few select files I want pulled?
This question asks almost the same thing, but addresses 'cherry-picking' a single or group of commits. I seem to need to have a pull request with just a few files from within a larger commit.
I tend to make a lot of changes to a lot of files putting in debugging code then find a solution that may involve only a change to a file or two. I don't commit very frequently so I don't have have a commit that contains only the changes that fix the problem (and I like keeping the debugging hooks in my copy of the code.)
I'd like SourceTree or eGit/Eclipse to: 1) show me which files are different between two commits and 2) let me select which files to include in a pull request. Perhaps I could do some selective merge files in my current master head and the master of the upstream repo?
I think what you want to do is to check out a number of files from a given commit / tree / revision.
To do this use:
git checkout [tree-ish] -- [paths]
[tree-ish] is a git-ism that basically means a commit, tag or branch, or something that refers to one of those. So if you have a remote remotes/foo/bar and you want baz.c from that revision, you do:
git checkout remotes/foo/bar -- baz.c
A 'pull request' is not a git thing, but a github thing. You will need to do a git remote add to add the repo you want to pull, then use git fetch or git remote update to pull the relevant information, then use the appropriate branch name in the above to get the file(s) you want.
Say I have a repo and someone forks it. Then they do work and submit a pull request. But the code contains a large number of lines and/or it creates a GUI. I'd like to fetch it so I can actually see it run from Eclipse before merging it into my master. The options I've come up with are:
Create a second repo in EGit and clone directly from their fork.
Create a new branch just for them. Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request (without merging)
Always keep around a branch for them to use in their pull requests.
Besides setting up an organization on Github what else could I do?
Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request
They don't have to re-submit, it you test and merge first locally, as described in the "Merging a pull request" GitHub page.
git checkout master
git pull https://github.com/otheruser/repo.git branchname
If the local merge works, then you can go ahead and merge the pull request through the GitHub web interface.
GitHub has documented how to checkout a pull request.
As I have illustrated before in "What support for git namespaces exists in git hosting services", you can use refs/pull/<PRNumber>/head as remote pull reference, in command line or in Egit when, for instance, creating a new branch.
If the PR number is 123, you can simply use the EGit Pull action, and use pulls/123/head as reference.