3 ms·

This looks like a very sensible workflow in general. The one thing that worries me is long lived feature branches. This workflow is fine as long as features nev

This looks like a very sensible workflow in general. The one thing that worries me is long lived feature branches. This workflow is fine as long as features never take more than a few weeks. If it takes longer you end up with bugs that have been fixed on the development branch still appearing on various feature branches. Also if you do a lot of refactoring on a feature branch while development goes on in parallel there will be difficult merges. It is especially problematic when work on a feature stops for some reason and an old branch sits around for months. In general code should be merged to the development branch as soon as it is working, tested and reviewed, even if not all the functionality of the feature is done.

rimantas 12y ago
Did you miss the part about rebasing?
- TorKlingberg 12y ago
  It looks like rebasing is only done after the feature is complete. Maybe that was just a simplification.
  - rimantas 12y ago
    Why does it matter? All the fixes will already be there after rebase anyway.
    - pionar 12y ago
      The point is that if you're not continually merging development down into your feature branch, then rebasing becomes overly difficult. Merging can introduce bugs if not done correctly. At my company, we eschewed feature branches about a year ago. We have two branches - development and main, with a branch ("tag" in git speak, we use TFS) created for each release of our product (we're a software company, not a service company). Development happens in the development branch, and is merged up into the main branch after code freeze. This does not preclude us from releasing often. With judicious use of feature toggles, it's simple to release with a feature that's not done. Feature branches would just create a mess for us as there's necessarily many communicating parts between teams, and the number of feature branches required to keep them all in sync would be exponential.
snowwrestler 12y ago
Can't this be managed by feature branch owners regularly merging from development? If I was coming back to a feature branch that had been dormant for a while, the first thing I'd do is pull from development to catch up. Yeah, it might break the feature branch, but better to break it there than actually on development.

rimantas 12y ago

Did you miss the part about rebasing?

TorKlingberg 12y ago
It looks like rebasing is only done after the feature is complete. Maybe that was just a simplification.
- rimantas 12y ago
  Why does it matter? All the fixes will already be there after rebase anyway.
  - pionar 12y ago
    The point is that if you're not continually merging development down into your feature branch, then rebasing becomes overly difficult. Merging can introduce bugs if not done correctly. At my company, we eschewed feature branches about a year ago. We have two branches - development and main, with a branch ("tag" in git speak, we use TFS) created for each release of our product (we're a software company, not a service company). Development happens in the development branch, and is merged up into the main branch after code freeze. This does not preclude us from releasing often. With judicious use of feature toggles, it's simple to release with a feature that's not done. Feature branches would just create a mess for us as there's necessarily many communicating parts between teams, and the number of feature branches required to keep them all in sync would be exponential.

snowwrestler 12y ago

Can't this be managed by feature branch owners regularly merging from development? If I was coming back to a feature branch that had been dormant for a while, the first thing I'd do is pull from development to catch up. Yeah, it might break the feature branch, but better to break it there than actually on development.