Hacker News Reader

Comment by michaelgrafl | Hacker News Reader

Point 2 (Branch off development) confuses me.

At my workplace we have branches for dev, staging, and production. We're working on feature branches. Now if my coworker merges feature A into dev, and I merge feature B into dev, and feature A is done and ready for release, but feature B needs more work, and my coworker checks out a new feature branch C from dev, he'll be unable to merge into production without merging in my unfinished feature B.

We branch off of production so this won't happen. Are we doing it wrong?

View on HN

Couldn't you merge the features that are done to your staging branch and from there merge to production? Your staging branch would be the 'release branch' in this model: http://nvie.com/posts/a-successful-git-branching-model/

Thanks for the link.

We merge feature into dev when we want to show a feature to a fellow developer.

We merge feature into staging when a feature is ready to be tested by non-developers and to be included in documentation.

We merge feature into production when it's ready for all users.

Has been working out well so far.

> We merge feature into dev when we want to show a feature to a fellow developer.

Wouldn't you just show them the feature branch?

We have a similar process it allows for more releases. imo there are things that require more testing then others, and they shouldn't hold up the process of releasing code.

It only makes sense to branch off production for hotfixes IMO.

In your example feature-B shouldn't have made it to dev.

Why would we need a dev branch at all then, and not just work on our local branches and merge with staging?

We might be discussing semantics, but try to see staging as a pre-production environment. You want to test the changes prior to deployment in an environment that is as close to production as possible, clean and accurate, while develop stays lean and dirty.

For some projects though this is a bit overkill and if you don't think this is important chances are you can get away with something more akin to the branching model rorykoehein posted.

In theory yes, a feature that requires more work shouldn’t make it’s way into dev really.

But I don't always know it will require more work.

We have the same setup, except that you never merge your feature branches anywhere but development. Then dev is merged to staging and deployed for testing and then, when that's all ready to go (potentially after multiple dev->staging merges to fix issues), staging is merged to production and deployed.

It seems really odd to me to branch from master for a feature branch, then push that to master, then push the feature branch to staging, and then push the feature branch to production. Is that what you are doing?

Why do you have a branch for staging? Staging, to me, means deployment testing on an environment that matches (but is not actually) production. That means code should be considered ready for production before it lands on the staging server. Otherwise it's just another development server with a different name.

edit: spellign

My Team feature branches off master, which automatically merges into Production if all test pass on CI.

Reply on news.ycombinator.com