If you try to edit a file from a repo you can read, but not write-to, from the GitHub interface, it will fork the repo, make a branch for the edit, then send a PR from that branch. If you try this again in the future, you'll get a different branch.

It is possible to update a fork from the GitHub interface... you make a new pull request from the original tree to your fork, then accept that PR. If you just hit "Pull Request" when looking at your fork, you'll see a "reverse bases" link that will do this.

Is there a way to give collaborators read-only access to a private GitHub repo?

I have some projects I'd love for others to see, but I don't want the code to be in public at this point.

Collaborators can have "Read", "Read/Write", or "Admin" privileges. You can choose after you add them.

I don't have that option. I can see that Teams have it, but as an individual with a private repo, I only have the input for entering the username.

https://help.github.com/articles/what-are-the-different-acce...

https://help.github.com/articles/how-do-i-add-a-collaborator

https://help.github.com/articles/how-do-i-set-up-a-team

Guess I have to set up a Team/Org, before I can manage permissions.

Whoops, my mistake. You get the option after you add them as a collaborator. I'll fix my comment above, too.

I'm surprised that GitHub hasn't made git remotes easier to manage. If you fork a repo, AFAIK you have to manually add remotes to keep up to date with the upstream repo. When you fork a repo, why don't they automatically add an "upstream" remote and support git pull/fetch from the web UI?

They should really make another branch before making any changes and then offer that branch up for the merge, once it gets merged they can delete the branch and fast-forward the master branch. The other options would simply be using a form of "git reset" or "git rebase" to clean up their branch.

Yes, they could work from a branch, but then we'd have to give them read-write to the repo. There's no per-branch access control.

Working on a branch in their fork doesn't help. They still can't pull in updates from the original repo.

They can update their branch in their own repo manually ("git pull upstream; git push origin" or equivalent on their development machines).

Still it'd be awesome if GitHub supported this via a Web interface.

They kinda do... make a new pull request on the GitHub website, pulling from upstream into your fork, then accept it. It works quite well, except for the extra merge commit.

I think there might be some confusion here. All I suggested was the git flow model[1] AKA forking, making your own branch, changing things, and making a pull request on that branch and if it gets merged, you delete the branch and fast-forward master.

I don't see why they can't pull in updates from the original repo. Are they not adding it as a remote?

[1] http://nvie.com/posts/a-successful-git-branching-model/

"I don't see why they can't pull in updates from the original repo."

Because github doesn't provide a way to do that on the site. Git workflows that can be achieved entirely on github.com were that subject of the story, and my original comment.

Ah, I was a bit confused. GitHub's kind of in-between being a web-UI for git and simply a storage bin for git repos. If they wanted to add the functionality to pull (fetch and merge) they'd have to implement a lot more functionality to handle conflicts. Have you tried looking at the native GitHub clients? They might provide the functionality you're looking for.

I think jzelinskie's point is that if they make no changes on the main branch in their fork then they can fast forward that main branch.

I don't think it's possible on GitHub but I think Bitbucket has the ability to 'sync' a fork.

> _the missing piece that keeps this from being useful is that they can't keep their fork up to date using github.com_

yep, a year ago removed "Fork Queue" would come in handy there.