Why is it a bad practice to transfer your fork master branch?

Question

Most Git workflows say you never pass your master fork because then your main branch will diverge from the source. However, won't this work just to reinstall your commits (from your main branch) on the master server? I know this is a little more complicated, but I don’t understand why this is bad practice.

Answer 1

Most people probably won't want to reinstall every time they want to pull up because you will lose some history metadata (timestamps, potential compression, etc.). But for other people, this may not be a problem.

Another reason for pull requests. Ideally, you will have the content of your pull request on a topic branch, which then (hopefully) merges into your upstream, after which you simply delete this thread from the threads and pull it out of the wizard. Thus, you do not have the old (now duplicated) object that is still stored in your history.

There is something that can be said about the ability to keep your leading branch "clean" in the sense that at any time you can pull out your master and not have conflicts. Thus, 6 months after you have developed the fork, you can still look at what is “theirs” and what is “yours”.

Answer 2

This is technically possible, but confusing for the accompanying original repo.

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

Answer 3

We use git as the best svn. In this mode, checking directly to the master is normal.