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

41–50 of 66 posts

Re: GitHub Flow

#41

Post by freedrull »

pgr0ss wrote: post #27
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…

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.

Re: GitHub Flow

#42

Post by schacon »

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…

wrt that article, we don't run into these issues i think largely because we do something that seems straightforward to me that is for some reason not addressed in that article (unless i'm reading it wrong) which is to reintegrate (merge) from master into your feature branch rather often.

the article you mention seems to think that you can either have short lived feature branches or integrate them into master all the time, where we (and most people, i think) do the opposite - integrate master into the feature branches so they're never that far behind and then do the opposite to fast forward the feature branch into master when it's ready to deploy.

and yes, your mental model is off a bit - a branch in git is more like a bookmark in hg - multiple heads for a branch doesn't really make sense - every head is a branch, there is no such thing as an unnamed head.

Re: GitHub Flow

#43

Post by terinjokes »

tednaleid wrote: post #23
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.

Could you use a private BitBucket repo for this? BitBucket has the same kind of pull request functionality that I'd think you could use to emulate this continuous delivery style.

To be completely honest, I've never been satisfied with using BitBucket, doing anything is comparitively harder, and honestly it just feels like I'm using an incomplete GitHub clone. (and I really don't like support teams that are "creatively bankrupt")

I'll look into if the issues feature works for us, but me might have to roll something of our own.

Doesn't mean I won't make the pitch for Git yet again.

Re: GitHub Flow

#44

Post by schacon »

dasil003 wrote: post #35

Here's what I'm curious about that is not mentioned at all: How do they manage deployment to staging? At my company we typically deploy topic branches directly to staging, but we have fewer developers and slower pace. If multiple people need to deploy topic branches we set up an ephemeral staging branch that merges the multiple topic branches together, but I can imagine that getting super hairy on a team the size of…

it depends. when staging is in a good state we'll simply ask if anyone is using it. you can see a few deployments to staging in that screenshot i posted i believe. however, if the developer judges that a ci pass is good enough, a deployment directly to prod after they get the ci green light is also common.

this is also one of the benefits of deploying via a chat room - you can ask if you're going to be stepping on anyone before you do it.

Re: GitHub Flow

#45

Post by nosequel »

jerhinesmith wrote: post #5

"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…

I don't use jenkins, I use buildbot, but I'm sure it is quite similar. If you use github's post-receive hooks it reports all branches not just master when something changes. So if jenkins can build from a posted JSON object, it is quite simple to do. On our top level project if anyone checks into a topic branch it is built and tested automatically.

Re: GitHub Flow

#46

Post by nosequel »

Aqua_Geek wrote: post #2

I wasn't aware that you can open pull requests from within the same project (i.e. not from a fork). The idea of using this for quick code reviews before merging code into the production branch is really interesting to me...

Most people using github for their everyday work do it the way Scott mentioned. Github's pull request system is fundamental to its success and everyone I know's workflow.

Re: GitHub Flow

#47

Post by mikagrml »

adgar wrote: post #12
jerhinesmith wrote: post #5

"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…

I don't think it's possible with the typical git/github plugins out of the box. However, Jenkins lets you run any manner of scripts at different parts of the build. One simple (perhaps too simple) way to implement this would be to run a script which enumerates branches and exports the name of the most recently touched branch to an environment variable. Then, parameterize the build on that environment variable.

Your approach is valid. We're doing something similar (e.g. auto-building Debian packages on each commit/push) and use git's post-receive and svn's post-commit hook to detect the modified branch and then trigger a parameterized Jenkins build which takes the branch as argument. You can even trigger different kinds of builds/tests/... depending on the branch name. Due to the nature of branching inside Git it's much more fun with Git, but it basically works for subversion as well.

Re: GitHub Flow

#48

Post by OWaz »

randall wrote: post #10

One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)

I try to commit when I have made enough changes so that builds and functionality don't break but not everything is 100% done either. My commit comment will describe what I was doing and what I changed. If unit tests pass then I think it's fine to commit (if you aren't writing unit tests than I advise that you should). There are projects I have to share with other developers and projects that I am the only developer on and I keep my rule of committing the same for both.

Re: GitHub Flow

#49

Post by pgr0ss »

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.

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.

Re: GitHub Flow

#50

Post by rsanheim »

xbryanx wrote: post #40
jerhinesmith wrote: post #5

"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…

Exactly! I'd love to see a post with this much detail talking about the technicals of their deploy process. Using this free-wheeling branching model, requires some very flexible deploy tools, which I don't think(?) exist in the wild. Please school me...

You use the github plugin with Jenkins, and tell Jenkins to build all branches. That's about it.

edit: more details here -- this is what Relevance uses for our CI: https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin

Post reply on HN