4 ms·

> Keeping master ready to deploy is the way to go Are there really teams that don't do this?

SAI_Peregrinus 7y ago
I work on an embedded device. Our tests include power analysis testing in LTE/GPS simulators of all the sleep/wake states. Total testing of a release takes about two weeks. Trying to keep master consistent without git-flow means we get PRs sitting around for a month and merge-conflict hell days when we merge everything to make a build to send to QA. Git-flow is bad if you have CD. Git-flow is great if you can't do that.
- AstralStorm 7y ago
  The part that's most contentious about git-flow is release branches. You still should merge often to develop, which when tested becomes master.
  - SAI_Peregrinus 7y ago
    The issue there is that you typically find some issues in testing, and need to fix them. That's why you test. You can either have a release branch and a develop branch, cherry-picking/merging fixes into the release branch as well as develop, or you can just hold off on merging any "not-for-this-release" branches for a few weeks. Just let the PR sit there. Alone. In the dark.
adrianN 7y ago
Any software that has more than a few dozen developers and has tests that run for more than a few minutes necessarily will have broken master states at least occasionally. Otherwise you slow everybody down because merging to master can only happen (working hours/test run time) times per day.
- viraptor 7y ago
  Openstack has the issue of long tests (nova takes two hours: https://review.opendev.org/#/c/711277/ https://review.opendev.org/#/c/711277/ ), but they still keep a green master. I don't think it's a problem in itself. The question is - why is anyone slowed down by merging? Why are people waiting for that action to happen? Merging can happen more than the (simple calculation) times a day though. What openstack does is check each branch on its own, but then tries to merge all a number of waiting PRs at one time. If they pass on fake master again, that's merged into real master.
  - SAI_Peregrinus 7y ago
    Github's interface is a big part of the issue (only for those using Github, of course). Say you branch off of master, make some changes, and make a PR. Call this branch A. Then you want to make a new branch, that depends on branch A. Call this branch B. The PR for branch A is still waiting to merge when you finish with branch B. If you make a PR to merge branch B to master, you get a diff showing both PRs worth of changes. That's annoying to review. If you make a PR to merge branch B to branch A, you get the correct diff for B. Huzzah! But if branch A's PR then merges, Github deletes the branch B PR and any comments/review. You have to remember to retarget branch B PR to master, then merge branch A.
- afiori 7y ago
  It is interesting how in such a case there is an increasing blur between git and blockchain.
- mcv 7y ago
  If you're using gitflow, you've got a separate develop branch that everybody merges to, while master remains stable. Only when develop works and passes its tests, can it be merged to master. And with multiple teams sharing the same code base, breaking master is going to slow a lot of people down a lot more. I have little experience with multiple teams working on a single code base, but it sounds like a recipe for disaster no matter how you organise that. Make your code as modular as possible, so each team can take responsibility for their own code.
- 7y ago
SlowRobotAhead 7y ago
Amazon FreeRTOS. Master is a working branch. Releases are pushed to Release and tagged with a date.

I work on an embedded device. Our tests include power analysis testing in LTE/GPS simulators of all the sleep/wake states. Total testing of a release takes about two weeks. Trying to keep master consistent without git-flow means we get PRs sitting around for a month and merge-conflict hell days when we merge everything to make a build to send to QA. Git-flow is bad if you have CD. Git-flow is great if you can't do that.

AstralStorm 7y ago
The part that's most contentious about git-flow is release branches. You still should merge often to develop, which when tested becomes master.
- SAI_Peregrinus 7y ago
  The issue there is that you typically find some issues in testing, and need to fix them. That's why you test. You can either have a release branch and a develop branch, cherry-picking/merging fixes into the release branch as well as develop, or you can just hold off on merging any "not-for-this-release" branches for a few weeks. Just let the PR sit there. Alone. In the dark.

adrianN 7y ago

Any software that has more than a few dozen developers and has tests that run for more than a few minutes necessarily will have broken master states at least occasionally. Otherwise you slow everybody down because merging to master can only happen (working hours/test run time) times per day.

viraptor 7y ago
Openstack has the issue of long tests (nova takes two hours: https://review.opendev.org/#/c/711277/ https://review.opendev.org/#/c/711277/ ), but they still keep a green master. I don't think it's a problem in itself. The question is - why is anyone slowed down by merging? Why are people waiting for that action to happen? Merging can happen more than the (simple calculation) times a day though. What openstack does is check each branch on its own, but then tries to merge all a number of waiting PRs at one time. If they pass on fake master again, that's merged into real master.
- SAI_Peregrinus 7y ago
  Github's interface is a big part of the issue (only for those using Github, of course). Say you branch off of master, make some changes, and make a PR. Call this branch A. Then you want to make a new branch, that depends on branch A. Call this branch B. The PR for branch A is still waiting to merge when you finish with branch B. If you make a PR to merge branch B to master, you get a diff showing both PRs worth of changes. That's annoying to review. If you make a PR to merge branch B to branch A, you get the correct diff for B. Huzzah! But if branch A's PR then merges, Github deletes the branch B PR and any comments/review. You have to remember to retarget branch B PR to master, then merge branch A.
afiori 7y ago
It is interesting how in such a case there is an increasing blur between git and blockchain.
mcv 7y ago
If you're using gitflow, you've got a separate develop branch that everybody merges to, while master remains stable. Only when develop works and passes its tests, can it be merged to master. And with multiple teams sharing the same code base, breaking master is going to slow a lot of people down a lot more. I have little experience with multiple teams working on a single code base, but it sounds like a recipe for disaster no matter how you organise that. Make your code as modular as possible, so each team can take responsibility for their own code.
7y ago

SlowRobotAhead 7y ago

Amazon FreeRTOS. Master is a working branch. Releases are pushed to Release and tagged with a date.