5 ms·

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 c

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?

ryanmacg 12y ago
In theory yes, a feature that requires more work shouldn’t make it’s way into dev really.
- michaelgrafl 12y ago
  But I don't always know it will require more work.
rorykoehein 12y ago
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/ http://nvie.com/posts/a-successful-git-branching-model/
- michaelgrafl 12y ago
  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.
  - IanCal 12y ago
    > 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?
  - securingsincity 12y ago
    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.
huehue 12y ago
It only makes sense to branch off production for hotfixes IMO. In your example feature-B shouldn't have made it to dev.
- michaelgrafl 12y ago
  Why would we need a dev branch at all then, and not just work on our local branches and merge with staging?
  - huehue 12y ago
    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.
snowwrestler 12y ago
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
madlynormal 12y ago
My Team feature branches off master, which automatically merges into Production if all test pass on CI.
malyk 12y ago
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?

ryanmacg 12y ago

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

michaelgrafl 12y ago
But I don't always know it will require more work.

rorykoehein 12y ago

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/ http://nvie.com/posts/a-successful-git-branching-model/

michaelgrafl 12y ago
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.
- IanCal 12y ago
  > 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?
- securingsincity 12y ago
  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.

huehue 12y ago

It only makes sense to branch off production for hotfixes IMO. In your example feature-B shouldn't have made it to dev.

michaelgrafl 12y ago
Why would we need a dev branch at all then, and not just work on our local branches and merge with staging?
- huehue 12y ago
  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.

snowwrestler 12y ago

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

madlynormal 12y ago

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

malyk 12y ago

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?