Don’t Start Pull Requests from Your Main Branch

When contributing to other users’ repositories, always start a new branch in your fork.

This may sound like pedantry or forcing the Right Way™ to do things on you. It’s not – I’m trying to save you (and the benefactor of your contribution) pain.

Here are the three main reasons:

1. You can only work on one pull request at a time, unless you can stack the new pull request on top of the old one. You can have just one fork and there’s just one main branch.

   This can get annoying faster than one think. For example, if you need to fix something small before doing the main work.

2. If the target repo merges your pull request (yay!), you can’t pull from it anymore because you’ve got conflicting commits (boo!).

   How complicated it is to recover from this situation depends on the target repo’s merge strategy. In the worst case (you had more than one commit in the pull request and the maintainer does a squash-and-merge for a clean history), you’re looking at a git reset --hard – or just nuking the fork and starting over.

3. If the target repo has branch protection on (many do), the “Allow edits from maintainers.” checkbox becomes meaningless and maintainers can’t push to your branch. Meaning: all changes have to go through you¹.

All the above is based on earned experience by yours truly.

Help! I’ve already started working on main!

You’ve got commits on main that you want to propose in a pull request? No worries, it’s not too late! You can still create a new branch and then delete the commits on the main branch. They’ll stay around on the new branch that you can push and use for your pull request.

If that sounds scary or you don’t know how, I can’t recommend Lazygit enough. It’s a Git TUI that doesn’t hide Git and its concepts from you, but makes everything easier and more logical. In this case, you’d go to the commits pane and press d on the commits you want gone – done!