5 ms·

This can become very problematic. For example: Team is working on feature A and feature B. Each feature is developed on its own branch. Feature A is ready fo

This can become very problematic. For example: Team is working on feature A and feature B. Each feature is developed on its own branch. Feature A is ready for testing/integration, it is merged into develop. Feature B is ready, it is merged into develop. Now here is the problem: Feature B is ready for release, but feature A is not. It is now not possible to merge develop into master without including both features. The solution I use is to have master and branches. That's it. Master represents currently-running production code. Branches contain everything else. This also happens to be how Github work. This article explains how it works with various levels of deployment before production - http://githubengineering.com/deploying-branches-to-github-com/ http://githubengineering.com/deploying-branches-to-github-co...

solutionyogi 11y ago
If you need independent release cycle for Feature A / Feature B, you adjust GitFlow by basing all branches (feature/release/hotfix) from the master. Let's say next release is Release-1.10 1. We merge Feature A and Feature B to it. 2. Feature A is tested and ready to be deployed. Feature B is not. 3. You either revert Feature B commit OR re-create the release branch with only Feature A. 4. Deploy the release branch. 5. Merge the release branch in to master. This is exactly what we do at my current workplace where we have 4 developers working on changes with different release schedule.
- jrochkind1 11y ago
  And then do you need the 'develop' branch at all? If not, you're describing something similar to what OP is.
  - solutionyogi 11y ago
    Yes, 'develop' branch is still useful. See my comment on that here: https://news.ycombinator.com/item?id=9744787 https://news.ycombinator.com/item?id=9744787
maratd 11y ago
I'm a bit confused, why are you merging things into develop if they're not ready? If Feature B isn't ready, it should stay in its own branch until it is. Develop is for code that the developers say is ready. You might have bugs, poor merge resolution, etc, but any fixes made should be quick and should pave the path toward code that can be merged into master. If the problems are major, revert develop. Master, on the other hand, should always be stable and rock solid. You can then have production servers that always pull master automatically, and staging servers that always pull develop automatically. I've worked on multiple teams this way it works out quite well.
- pc86 11y ago
  In the above example, say Feature A gets the go-ahead from the business user/product owner/whatever, and Feature B doesn't. From the dev standpoint both are complete but there may be some business reason to hold up Feature B. The owner(s) of Feature A are likely not going to understand why anything to do with Feature B has to hold up their release.
  - jkyle 11y ago
    If part of the process is required approval by some customer/business exec, etc. . . don't merge it till it's approved.
  - atomicUpdate 11y ago
    In your scenario, Feature B should not have been promoted into the development branch until everyone agrees it's going to be shipped. If it got into development without everyone's approval, then that is a business process problem, not a CVS tool problem. At my last job, we had a 'gorilla' that had to approve every commit, and it was his job to coordinate between the project managers and the developers as to what was allow to be promoted to prevent exactly the scenario you described. It also had the benefit of making developers describe each commit clearly so that the gorilla could understand the change, which made looking at the commit history some time later (months/years) quite a bit easier too.
    - 11y ago

solutionyogi 11y ago

If you need independent release cycle for Feature A / Feature B, you adjust GitFlow by basing all branches (feature/release/hotfix) from the master. Let's say next release is Release-1.10 1. We merge Feature A and Feature B to it. 2. Feature A is tested and ready to be deployed. Feature B is not. 3. You either revert Feature B commit OR re-create the release branch with only Feature A. 4. Deploy the release branch. 5. Merge the release branch in to master. This is exactly what we do at my current workplace where we have 4 developers working on changes with different release schedule.

jrochkind1 11y ago
And then do you need the 'develop' branch at all? If not, you're describing something similar to what OP is.
- solutionyogi 11y ago
  Yes, 'develop' branch is still useful. See my comment on that here: https://news.ycombinator.com/item?id=9744787 https://news.ycombinator.com/item?id=9744787

maratd 11y ago

I'm a bit confused, why are you merging things into develop if they're not ready? If Feature B isn't ready, it should stay in its own branch until it is. Develop is for code that the developers say is ready. You might have bugs, poor merge resolution, etc, but any fixes made should be quick and should pave the path toward code that can be merged into master. If the problems are major, revert develop. Master, on the other hand, should always be stable and rock solid. You can then have production servers that always pull master automatically, and staging servers that always pull develop automatically. I've worked on multiple teams this way it works out quite well.

pc86 11y ago
In the above example, say Feature A gets the go-ahead from the business user/product owner/whatever, and Feature B doesn't. From the dev standpoint both are complete but there may be some business reason to hold up Feature B. The owner(s) of Feature A are likely not going to understand why anything to do with Feature B has to hold up their release.
- jkyle 11y ago
  If part of the process is required approval by some customer/business exec, etc. . . don't merge it till it's approved.
- atomicUpdate 11y ago
  In your scenario, Feature B should not have been promoted into the development branch until everyone agrees it's going to be shipped. If it got into development without everyone's approval, then that is a business process problem, not a CVS tool problem. At my last job, we had a 'gorilla' that had to approve every commit, and it was his job to coordinate between the project managers and the developers as to what was allow to be promoted to prevent exactly the scenario you described. It also had the benefit of making developers describe each commit clearly so that the gorilla could understand the change, which made looking at the commit history some time later (months/years) quite a bit easier too.
  - 11y ago