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.
3 Answers
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".
7 Comments
rb612
That makes a lot of sense. Thanks! What do you mean by "This way you don't have your old (now duplicated) commits still in your history". How would they still be duplicated in the history?
Jonathan.Brink
Let's say you create a commit that you intend to share upstream. You make that commit on master (rebasing along the way perhaps) and then when it's time to share create a pull-request from that commit. Then, when that pull-request is merged in upstream, upon your next pull you will be pulling in a duplicate commit (content-wise). The rebase may clean up for you however, depending on any tweaks made by the upstream maintainer.
rb612
Hmmm...but wouldn't your local master branch already be in-sync with upstream? Once the original repo contributor pulls in your changes, I'd think upstream/master and local master would stay the same, but I could be missing something.
Jonathan.Brink
Good point...but if you are rebasing frequently to keep up to date your commit sha hash's will change, meaning you won't have that same commit anymore (same content, but different hash)
Jonathan.Brink
yep. Everytime you rebase, the commits that are not on the upstream you are rebasing against will be "re-written", meaning they may have the same content but different sha/timestamp.
|
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
Comments
We are using git as a better svn. In this mode, checking in directly to master is normal.
masterandremote/masterdifferent, but that's pretty much a matter of opinion and whatever workflow you prefer. Cherry-picking and rebasing can be used to select relevant commits from your own master to a new topic branch that will be pushed.