

GitHub Flow in the Browser - davidboy
https://github.com/blog/1557-github-flow-in-the-browser

======
freshhawk
"doing this in the terminal requires a crazy number of steps"

"Switching contexts from your browser into your terminal."

"you can simply make the change right there without leaving your browser,
saving you time and maintaining your zen-like frame of mind"

Sending a pull request for a typo in someone else's project is way faster
using the github web editor, no question, but for everything else?

I'm in a terminal or, most likely, my editor way more often than I'm in the
browser and for any non-trivial change it's way faster to use git in the
terminal or fugitive (vim-git integration) than the web interface.

Once you have to use the proprietary pull request functionality to send that
change it changes the balance a bit but that's just saying that Github's
vendor lock-in strategy that forces you to use the Github site makes it faster
to use the Github site than both the site and the git command. Not a bragging
point, just a reminder that I should be nervous about Github having gotten as
far as "embrace" and "extend" in the microsoft playbook even though I really
like Github.

[http://www.wired.com/wiredenterprise/2012/05/torvalds_github...](http://www.wired.com/wiredenterprise/2012/05/torvalds_github/)

[http://julien.danjou.info/blog/2013/rant-about-github-
pull-r...](http://julien.danjou.info/blog/2013/rant-about-github-pull-request-
workflow-implementation)

~~~
joshuacc
"I'm in a terminal or, most likely, my editor way more often than I'm in the
browser and for any non-trivial change it's way faster to use git in the
terminal or fugitive (vim-git integration) than the web interface."

I've no doubt that this is true for you, but other users have very different
situations.

I'm a front-end developer, which means that I live in the browser. For me, if
it's just a simple change, I'd much rather do it from the browser than the
terminal. This is despite the fact that I know the terminal pretty well (love
tmux and tmuxinator, for example).

~~~
freshhawk
Oh yeah, I have no doubt that's true for a lot of people but as far as I know
you folks are still a small minority.

Even when I'm doing CSS and I spend a lot of time in firebug/dev tools that's
just for experimentation, the first step before interacting with git is still
changing some file which I do in an editor. Although I also use a lot of "live
preview triggered on save" type workflows rather than building stuff in the
browser which I know is unusual (not for long I'm guessing).

------
unfletch
We have some marketing people who want to make trivial updates to our site,
but we don't want to give them write access to the entire repo.

We've given them read-only access so they can fork the repo, make edits and
send us (engineering) pull requests. But the missing piece that keeps this
from being useful is that they can't keep their fork up to date using
github.com. The best they can do is delete the fork and fork again, which
stinks.

Is the ability to pull new commits from the original repo into your fork
actually missing from github.com, or are we missing it?

~~~
kmfrk
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.

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

~~~
kmfrk
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/what-are-the-different-access-
permissions)

[https://help.github.com/articles/how-do-i-add-a-
collaborator](https://help.github.com/articles/how-do-i-add-a-collaborator)

[https://help.github.com/articles/how-do-i-set-up-a-
team](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.

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

------
Shank
I've already experienced some of this flow having experience grabbing pull
requests from new developers. Typo fixes or simple one liners are dead simple
to add in browser and not over command line.

I only worry this will encourage people new to git to copy paste files for
changes into a fork on Github directly instead of cloning for big changes
manually. We'll have to see how it plays out.

~~~
ethomson
Why is copying and pasting to be discouraged?

~~~
daleharvey
And why is forking encouraged? its one of my largest pet peeves with github, I
cant just clone someones repo, make a patch in a branch and email / send it
off, I need to fork the repo and make a pull request.

I dont like having to go to the effort and litter my repository list with
repos I want to send a couple of line fixes too.

* Obviously I can, but its more hassle for the owner and less likely to be accepted

~~~
grannyg00se
How is cloning a benefit over forking? Either way you end up with the
repository littering your list.

I suppose if you clone you could immediately delete the clone after submitting
the patch, but that seems premature. In both cases, you can delete the repo
after the patch is applied, couldn't you?

~~~
delluminatus
Well, cloning is a git thing, not a github thing. Cloning repositories doesn't
put them on your github repository list.

------
ataggart
I look forward to the day when code reviewing a pull request with a
significant number of commits across a significant number of files is possible
for a human. The top/bottom diff format may be useful for machines, but it's
terrible for understanding what actually changed. It'd also be nice if there
was some facility for stepping through versions of a given file.

~~~
cpeterso
Most visual diff tools use side-by-side diffs. I will occasionally write code
in a visual diff so I can compare my new fix with the old code when debugging.

Review Board (reviewboard.org) is a web-based code review tool that uses side-
by-side diffs.

~~~
mhartl
Bitbucket has side-by-side diffs.

------
jlarocco
This seems kind of silly. When would a person ever want to remove a file but
not check that the changes didn't break anything?

In fact, as much as I like GitHub, using it entirely from the web interface
seems a little dangerous in general. The only scenario where I see it being
useful is for changes along the lines of fixing spelling mistakes. Everything
else it's stupid not to test it before pushing...

~~~
lukehorvat
If there is nothing to build. Not everything version-controlled with Git has
to be runnable software.

------
BHSPitMonkey
> <h3>Less distruptive workflows</h3>

Quick, somebody submit a pull request to the blog repository! :)

------
jmgrosen
Is it possible to create/delete/move directories yet? I found myself wanting
to do that just yesterday.

~~~
ben_straub
Git doesn't track directories directly, but you can create files in
subdirectories. Go to <user>/<repo>/new/<branch> (or click the little "+" box
where the path is displayed), and type "foo/bar" in the filename box.

