10

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.

rb612
  • 5,280
  • 3
  • 30
  • 68
  • 3
    This really depends on what you're doing. There's not going to be one right answer. – Chris Martin Nov 17 '15 at 05:35
  • @ChrisMartin so could you give an example of when it's going to be an issue and when it's OK? – rb612 Nov 17 '15 at 05:36
  • 2
    This strikes me as one of those useful questions that should be an exception to the "opinion-based" rule. – Tom Zych Nov 17 '15 at 09:36
  • 1
    @TomZych I wholeheartedly agree. – Markus W Mahlberg Nov 17 '15 at 10:22
  • I'd say it's totally OK to commit things to your master branch, as long as you make sure to base every topic branch/pull request on the shared master (or relevant shared branch). It might be said that it'd be confusing to you to have `master` and `remote/master` different, 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. – MicroVirus Nov 17 '15 at 21:10

3 Answers3

6

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".

Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
  • 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? – rb612 Nov 17 '15 at 05:45
  • 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. – Jonathan.Brink Nov 17 '15 at 05:49
  • 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. – rb612 Nov 17 '15 at 05:53
  • 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 Nov 17 '15 at 05:56
  • Oh that's a good point! That's because the timestamp would be different, right? – rb612 Nov 17 '15 at 06:08
  • 1
    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. – Jonathan.Brink Nov 17 '15 at 06:13
  • Thanks so much for being so thorough and helpful! – rb612 Nov 17 '15 at 06:14
3

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
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

We are using git as a better svn. In this mode, checking in directly to master is normal.

Joshua
  • 40,822
  • 8
  • 72
  • 132