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

21–30 of 66 posts

Re: GitHub Flow

#21

Post by tednaleid »

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 working off the same named branch.

Are there any race conditions with merging to master? I'm assuming that only one head is allowed in master, correct? So that before a pull request is accepted and merged into master, the latest master must first be merged into the feature branch and have CI run all tests successfully on it before the pull request can go. Does GitHub stop you from merging into master if someone else just merged into master and you're about to create a new head?

Then you have to merge the latest master into your feature branch, run CI on it again and then merge to master after CI is successful (assuming someone else didn't beat you to merging to master again).

(I've got a lot more experience with Mercurial than Git so my mental model could be a little off)

Re: GitHub Flow

#22

Post by gnufied »

Pewpewarrows wrote: post #15
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.)

It's really a judgement call, although I'd definitely recommend against committing every single save. The only hard-fast rule I follow is to always commit whatever I have left-over at the end of the day, so that I never lose work overnight or over a weekend. Other than that, if you felt like you've taken a decently-sized chunk out of whatever problem or feature you're currently working on, commit.

I think you are confusing committing with pushing? But even then, I do not see any harm in pushing often, you can always amend your commits before final merge or pull request.

Re: GitHub Flow

#23

Post by tednaleid »

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.

Re: GitHub Flow

#24

Post by gnufied »

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.

Re: GitHub Flow

#25

Post by dasil003 »

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…

> Are there any race conditions with merging to master? I'm assuming that only one head is allowed in master, correct? So that before a pull request is accepted and merged into master, the latest master must first be merged into the feature branch and have CI run all tests successfully on it before the pull request can go. Does GitHub stop you from merging into master if someone else just merged into master and you're about to create a new head?

One useful thing to keep in mind for this explanation is that GitHub doesn't do anything really, it's just one more git repo with a bunch of sugar.

Yes, there is only one HEAD for a branch in any given repo. When you push it expects that your local HEAD is a direct descendant of the remote HEAD. If this is not the case (due to someone pushing since you last pulled) then it won't do anything (you can force it, but that's almost always a bad idea). In practice though this is not a big issue. You don't have to remerge into the topic branch. Instead you can just reset your master HEAD to origin/master and then remerge the topic branch into master and then push.

If you are just working on changes locally directly on master, it's even easier, you just do git pull --rebase and all your local changes are rebased to the latest HEAD.

Re: GitHub Flow

#26

Post by paydro »

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 tend to do a lot of work upfront (without committing) and then go back and split the work up into smaller commits with "git add -p". I commit often, so it's never a huge list of changes I have to split.

I do this so I can cherry pick commits into other branches (e.g., fixing a bug in my current branch and merging it back to master).

Re: GitHub Flow

#27

Post by pgr0ss »

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

Re: GitHub Flow

#28

Post by dasil003 »

Pewpewarrows wrote: post #6

Very good comparison between workflows of deploying several times per day versus much less often. While it might not be obvious to some, the exact same git "flow" won't work for both. Your tools should complement your corporate culture, not the other way around. I think the most important thing to note from either method, though, is not to develop on master/trunk. Have a separate branch, or further branches off an en…

Yes, however the only factor here that implies never working off master is the peer review. If one dev can take responsibility for the stability of a patch, then it's perfectly okay to work off of master locally and push when it's stable. If you need to put this work on hold or it grows into something requiring a topic branch, at any time you can simply do:

git branch new_topic_branch && git reset --hard origin/master

Re: GitHub Flow

#29

Post by cmer »

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.

Re: GitHub Flow

#30

Post by dasil003 »

DamagedProperty wrote: post #16
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 like to think about my commits as units of work that I can pull back or cherry pick if I want to. It doesn't always work out that way. Make sure your commits are cohesive to the change you are making. I think that is a good rule of thumb.

Yes, definitely nice if you can make your commits atomic changes. The more easily able to right a nice summary line (50 chars please!) the better.

On the other hand, some changes are big and messy. In this case I sometimes do intermediate commits, especially if it's at the end of a day just so I can keep yesterdays changes conceptually separate from todays. In the end I may rebase -i the whole thing and clean things up before pushing, but only if there are some obvious and quick ways to split it up.

Post reply on HN