GitHub Flow in the Browser

https://github.com/blog/1557-github-flow-in-the-browser

by davidboy • 13 years ago

117 36 13 years ago

Shank• 13 years ago

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• 13 years ago

Why is copying and pasting to be discouraged?

daleharvey• 13 years ago

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

BHSPitMonkey• 13 years ago

<h3>Less distruptive workflows</h3>

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

jmgrosen• 13 years ago

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

ben_straub3• 13 years ago

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.

unfletch3• 13 years ago

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?

kmfrk2• 13 years ago

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_straub3• 13 years ago

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

jzelinskie3• 13 years ago

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.

unfletch3• 13 years ago

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.

jameswyse• 13 years ago

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

cpeterso2• 13 years ago

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?

unwiredben2• 13 years ago

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.

develop7• 13 years ago

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

freshhawk2• 13 years ago

"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://julien.danjou.info/blog/2013/rant-about-github-pull-r...

joshuacc• 13 years ago

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

freshhawk2• 13 years ago

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

natrius• 13 years ago

Github has a git wrapper that adds commands for their extra functionality. Pull requests can be done from the command line.

https://github.com/github/hub#git-pull-request

ataggart• 13 years ago

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.

cpeterso2• 13 years ago

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• 13 years ago

Bitbucket has side-by-side diffs.

jlarocco• 13 years ago

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• 13 years ago

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

GitHub Flow in the Browser

Related Stories