Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Flow

scottchacon.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: GitHub Flow

#51

Post by rsanheim »

cmer wrote: post #29
gnufied wrote: post #24

Its interesting that they abandoned CI Joe. I wouldn't say, I saw this coming. But, unless they wanted to maintain/write a full blown CI server themselves, it would have got harder for multiple projects.

Indeed. I'd love to hear the details on this. I was considering CI Joe for a project.

This isn't surprising to me. While CI Joe was decent and simple, its really extremely limiting once you want to do anything moderately complicated.

Jenkins has a crummy UI, but it is very powerful and has a lot of useful plugins. If you are moving to any sort of continuous deployment setup, as Github is close to, you really need something as powerful as Jenkins.

Re: GitHub Flow

#52

Post by cpeterso »

freedrull wrote: post #41
pgr0ss wrote: post #27

Earlier quoted context omitted.

I actually just wrote up a blog post as well about why I don't like feature branches: http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branc... My main reasons are that git history gets messy, builds don't run on feature branches (although github seems to have a work around here), and refactoring is harder. My opinions are largely based on working on larger projects (more than 10 devs working in the same codeba…

Learn to use rebase and squash commits! It solves a lot of the issues you talked about.

Ironically, it seems like more feature branches is the solution to the "feature branch problem". :) With more, smaller branches, their changes will be laser-focused and easier to squash.

Re: GitHub Flow

#54

Post by simonw »

pgr0ss wrote: post #49
freedrull wrote: post #41

Earlier quoted context omitted.

Learn to use rebase and squash commits! It solves a lot of the issues you talked about.

Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.

GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".

Re: GitHub Flow

#55

Post by simonw »

Question about the chat deploy bot: there are a few lines in there that look like this:

    hubot deploy github/ghost-down to production
Is that deploying a branch directly to production, or does that cause a branch to be merged with master and then master deployed to production? If the former, why deploy a branch directly rather than sticking to the "master is production" idea?

Re: GitHub Flow

#56

Post by kevingessner »

terinjokes wrote: post #18

For reasons decided long ago, the company I'm at uses Mercurial, and I don't think we're in a position to retrain everyone and move to a private GitHub repo. Anyone know of ideas for doing code reviews for the whole pull request, commit, or a single line like GitHub? This is probably the most beneficial part for us.

If you're using Mercurial, Kiln offers code reviews and repository management, hosted by us or on your server.

http://www.fogcreek.com/kiln/

(disclosure: I work on Kiln at Fog Creek)

Re: GitHub Flow

#57

Post by kneath »

simonw wrote: post #55

Question about the chat deploy bot: there are a few lines in there that look like this: hubot deploy github/ghost-down to production Is that deploying a branch directly to production, or does that cause a branch to be merged with master and then master deployed to production? If the former, why deploy a branch directly rather than sticking to the "master is production" idea?

It's deploying a branch to production.

If you think about it, this is completely the example of "master is production-ready" idea. We care so much about keeping master deployable, that if we have code that may have issues and need to be rolled back, we deploy just the branch. That way if things break, you can "roll back" to master and everything is good again.

Re: GitHub Flow

#58

Post by technoweenie »

tednaleid wrote: post #21

This sounds like a feature branch strategy, which I've only used in 1 or 2 person teams, never on projects that big. There have been some articles recently on the downsides of feature branching that my experience agrees with ( http://continuousdelivery.com/2011/07/on-dvcs-continuous-int... ). I'm curious if the GitHub people have hit the same issues. So if 2 people are working on the same feature, they're probably wo…

Yes, there's always a race condition merging to master. Occasionally I'll want to deploy something, but jenkins builds pile up, or someone is busy test-deploying a feature branch. Since we deploy from our chat room, we naturally talk about what we're doing in the same spot.

Also, if you have too many developers on the same project, break the project up into smaller pieces. We have various systems in separate repos that can be rolled out independently.

Re: GitHub Flow

#59

Post by geeksam »

For those who enjoyed this talk, Corey Donohoe gave an awesome presentation at Cascadia RubyConf that goes into more detail about what they use Hubot for, and also mentions deploying branches to a subset of their boxes. It was one of the best talks of the conference: http://confreaks.net/videos/608-cascadiaruby2011-shipping-at...
Post reply on HN