6 ms·

The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works

The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness" - branches: Work in progress. - develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world. - master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests. As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...

mmgutz 11y ago
I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.
- Touche 11y ago
  Why not just use tags?
  - simias 11y ago
    You might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).
    - Touche 11y ago
      Sure, you can do that with tags. Branch off from your tag, cherry-pick your commits, push and if tests pass create a new tag.
  - ryanbrunner 11y ago
    We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)
- magicmu 11y ago
  I do something very similar; use master for dev builds that can be shared (since it's the default branch) and something like 'deploy' or 'deployprod' (which on second thought is a bit redundant) for release. Then, using a CI tool, you can have master go to a staging environment and deployprod go to production.
- pc86 11y ago
  What would be an example where master differs from production?
- jes5199 11y ago
  all code is release code
the_af 11y ago
This is how my team works. I always thought GitFlow was way too complex for our use case. The way you describe seems to work for us, mostly. There are still the occasional mistakes and commits to the wrong branch, often accidentally bypassing develop, which I guess supports the article's premise.
Alexandervn 11y ago
Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people. - Feature branch: do whatever you want - Develop: should be good enough for the client (product owner) to look at - Release branch: should be good enough to be tested by the test/QA team - Master: should be good enough for website visitors Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.
- Touche 11y ago
  The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.
  - madeofpalk 11y ago
    I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.
    - Touche 11y ago
      That doesn't work in practice, you are always going to need to "fast-track" a bug fix, skipping develop (which has code you don't want to deploy).
      - rjv 11y ago
        That's exactly what hotfixes are for. A completed hotfix will merge directly into develop and master simultaneously (practically speaking). This allows you to keep your unrelated develop commits out of the master until you're ready to merge it all.
BillinghamJ 11y ago
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.
Eridrus 11y ago
Does having a lower level of quality on develop hinder your ability to actually release code? We have one particular repo at work that is just a pain in the ass to work with (Typescript analytics code that has to be backwards compatible to about forever), and we've pretty much abandoned the develop branch since releases got held up due to bugs in less important features that had been merged in without comprehensive testing. Pretty much everything now gets tested extensively on a feature branch and then gets merged directly into a release branch. We might have swung a little too far in the other direction, I'm thinking we want to at least merge well tested bits back onto develop, but at least we can release the features that are actually done and cut those that are still having issues without having to do any major git surgery.
- krisdol 11y ago
  > We might have swung a little too far in the other direction I think you're describing "GitHub flow", or how most people starting out with git would probably use it given no exposure to git-flow. Github flow introduction: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html Documentation (it's really unnecessary if you get the idea): https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/

mmgutz 11y ago

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

Touche 11y ago
Why not just use tags?
- simias 11y ago
  You might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).
  - Touche 11y ago
    Sure, you can do that with tags. Branch off from your tag, cherry-pick your commits, push and if tests pass create a new tag.
- ryanbrunner 11y ago
  We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)
magicmu 11y ago
I do something very similar; use master for dev builds that can be shared (since it's the default branch) and something like 'deploy' or 'deployprod' (which on second thought is a bit redundant) for release. Then, using a CI tool, you can have master go to a staging environment and deployprod go to production.
pc86 11y ago
What would be an example where master differs from production?
jes5199 11y ago
all code is release code

the_af 11y ago

This is how my team works. I always thought GitFlow was way too complex for our use case. The way you describe seems to work for us, mostly. There are still the occasional mistakes and commits to the wrong branch, often accidentally bypassing develop, which I guess supports the article's premise.

Alexandervn 11y ago

Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people. - Feature branch: do whatever you want - Develop: should be good enough for the client (product owner) to look at - Release branch: should be good enough to be tested by the test/QA team - Master: should be good enough for website visitors Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.

Touche 11y ago
The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.
- madeofpalk 11y ago
  I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.
  - Touche 11y ago
    That doesn't work in practice, you are always going to need to "fast-track" a bug fix, skipping develop (which has code you don't want to deploy).
    - rjv 11y ago
      That's exactly what hotfixes are for. A completed hotfix will merge directly into develop and master simultaneously (practically speaking). This allows you to keep your unrelated develop commits out of the master until you're ready to merge it all.

BillinghamJ 11y ago

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.

Eridrus 11y ago

Does having a lower level of quality on develop hinder your ability to actually release code? We have one particular repo at work that is just a pain in the ass to work with (Typescript analytics code that has to be backwards compatible to about forever), and we've pretty much abandoned the develop branch since releases got held up due to bugs in less important features that had been merged in without comprehensive testing. Pretty much everything now gets tested extensively on a feature branch and then gets merged directly into a release branch. We might have swung a little too far in the other direction, I'm thinking we want to at least merge well tested bits back onto develop, but at least we can release the features that are actually done and cut those that are still having issues without having to do any major git surgery.

krisdol 11y ago
> We might have swung a little too far in the other direction I think you're describing "GitHub flow", or how most people starting out with git would probably use it given no exposure to git-flow. Github flow introduction: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html Documentation (it's really unnecessary if you get the idea): https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/