Why is it bad practice to commit to your fork's master branch?

Question

Most Git workflows say to never commit to your fork's master because then your master branch will diverge from origin. However, wouldn't it work to just rebase your commits (from your master branch) on the upstream's master? I know it's a little more complicated, but I don't see why this is bad practice.

Answer 1

Most people would probably not want to rebase every time they want to pull from upstream because you lose some history metadata (timestamps, potential squashing, etc). But for other people this may not be an issue.

Another reason would be for pull-requests. Ideally, you would have the content of your pull-request on a topic branch which then (hopefully) get's merged into your upstream, after which you simply delete that topic branch and pull from master. This way you don't have your old (now duplicated) commits still in your history.

There is something to be said in the ability to be able to keep your master branch "pure" in the sense that anytime you want to can pull your master and have no conflicts. This way 6 months after you fork you can still at a single glance see what is "theirs" and what is "yours".

Answer 2

It is technically possible, but confusing for the maintainer of the original repo.

• any branch from the original repo should be updated by a git fetch upstream (not by your own fork as well)
• When you do a PR, the name of the branch is important to isolate and characterize the nature of your PR