I am posting this here mostly because inevitably I will forget this again, and in the future, when I once more scour the internet or tear through my old notes for an answer, perhaps I’ll come across my own blog post. 🤦🏻
Some background on why I wanted this
Recently I completed a code exercise for a job interview. I’d created my own repository for it, and as I often do, opened my own pull requests so I’m not just pushing to main all the time. Also, each pull request would give the reviewer a good idea of how my mind works when coding a project.
When I added the reviewers as contributors on the repository, although it wasn’t required, I wanted to provide an option for them to leave comments on a pull request for the entire repository. An interesting option, for sure! Usually, this isn’t done, because most of the people who would review code are already on your team. But, they weren’t on my team, and hadn’t had the opportunity to code review as I went along.
About code reviews and pull requests
When working with a code repository, there is a main branch that contains production-ready code and feature branches that contain work specific to a task. Changes that are proposed for inclusion in the production-ready code are done in feature branches so that nothing is affected on the live project! In nearly all development workflows, no individual piece of work is ever pushed directly to the main branch.
Code reviews are a way to mitigate any issues going into production. A pull request or a merge request provides developers a way to review each other’s changes, leave comments, and make suggestions for improvements. Developers can engage in a great discussion about what is understandable versus what is efficient, what can be rearranged to adhere to code style guides, or even just where the typo is that is causing that blasted bug (missing semicolon, anyone‽).
The whole chunk of commands for your terminal of choice
So here it is: the snippet of commands I use to open a pull request on the entire respository. I’ll include the whole chunk as one, then go through it line by line to explain what’s happening.
The following is generic for git, no matter which service you may host your respository on. Later in this post will be tips on opening a pull request using GitHub, Codeberg, or other services.
git checkout main
git pull
git checkout -b 20260430-review
git push origin 20260430-review
git checkout main
git checkout --orphan 20260430-empty
git rm -rf .
git commit --allow-empty -m "initial commit for an empty branch"
git push origin 20260430-empty
git checkout 20260430-review
git merge 20260430-empty --allow-unrelated-histories
git pushBreak it down, line by line
First, make sure you are on the main branch of your repository. Usually, this is main, but your team may have a different standard.
git checkout mainThen, grab the latest code from your main branch. You may already have it, but this ensures you do. It’ll be important when creating the review and empty branches.
git pullCreate the temporary review branch. This branch is basically a copy of your main branch, so you’ll have something to compare, but you don’t want to accidently mess up and delete everything on the main branch. Hence, the temporary branches!
You may want to tag it with the date you’re opening the pull request, so you know when these branches were, well, branched from your main branch.
git checkout -b 20260430-reviewPush this review branch to the repository. Because the review branch is new, you’ll need to use the origin attribute to keep the local branch synced with the remote branch.
git push origin 20260430-reviewCheckout your main branch again, since we’re going to create a new copy that will be empty.
git checkout mainCurrently on the main branch, you’ll create an temporary orphan branch that has no history! When creating the new branch, you’ll use the --orphan flag.
git checkout --orphan 20260430-emptyThis next step may seem scary (it always is to me!) but you’re in that new temporary empty branch, which won’t completely erase the code in your main branch. rm tells git to remove files, -rf tells it to include folders and everything inside, and . tells it to do that to everything in the project.
git rm -rf .With all the files removed, and with this being an orphan branch, git will think there is nothing to commit. Use the --allow-empty flag to tell git that, yes, you do indeed want to make an empty commit.
git commit --allow-empty -m "initial commit for an empty branch"Push this empty branch to the repository. Just like above, because the empty branch is new, you’ll need to use origin again.
git push origin 20260430-emptyOK, let’s go back to that review branch!
git checkout 20260430-reviewMerge the empty branch into the review branch. Since the empty branch was created as an orphan, use the --allow-unrelated-histories flag to tell git you now want them to share a history.
git merge 20260430-empty --allow-unrelated-historiesOne more push! This pushes the review branch back into the repository, but with the added merge of the empty branch.
git pushNow you’ve got two temporary branches to compare! One is a copy of the main branch, and one is completely fresh, like nothing ever happened.
Opening the pull request for code review
Both the temporary empy and review branches are pushed to the repository. It’s time to open the pull request! The empty branch will be used as the target or base and the review branch will be used as the compare.
Code reviewers can leave comments on the pull request, and if any changes are requested, they can be committed and pushed to the review branch. Once all comments are resolved and merged, the review branch will merge into the empty branch, which can then be merged into the main branch.
If there are no changes made to the review branch after a code review on the pull request, the pull request can be closed without merging, and nothing ever makes it into the main branch.
Repository resources
Below are links on pull requests for some common software repository platforms. git pull requests work differently from the following, as it is used in the command line.
Using Codeberg
The repository for this site is hosted on Codeberg, and the example here is based on that.
- After running through all the above steps for creating and pushing the temporary branches, go to the Pull Requests section of your repository on the Codeberg website.
- Click the New pull request button on this page, which will bring you to the user interface for creating the new pull request.
- Codeberg asks you to “Select the branch to merge into and the branch to pull from.” For the “merge into” branch, select your temporary empty branch, and for the “pull from” branch, select your temporary review branch.
- A preview of the changes will appear, which will be every line of every file in the repository. Click the New pull request button on this page to start the process.
- The user interface for the pull request appears, where you can set the title, description, assignees, and other attributes.
- After you fill out all the details, once you click the Create pull request button, you have your pull request on the entire repository!
Go forth and review!
Collaborate with friends or coworkers, make awesome changes to the code, and have fun! I hope this helps you or someone you know. I for sure guarantee this will help me again in the future.