3 ms·

The thing about develop is you should consider it at least a little volatile; you create the release branches to harden it before the merge into master (and bac

by choult 13y ago

The thing about develop is you should consider it at least a little volatile; you create the release branches to harden it before the merge into master (and back into develop). Using a script set such as git-flow really helps manage this without worrying too much. My only concern about using git-flow was that it was only really suitable on one repo; it doesn't really automate the transmission of the various branches to other repos. But then hubflow[1] sorts that one out. [1] http://datasift.github.io/gitflow/ http://datasift.github.io/gitflow/

geocar 13y ago
The thing about develop is that only one (or two) people have the requisite skill in a large codebase to move stuff from develop to master. Transferring that knowledge is time-intensive and expensive. Scripts don't solve that problem because it isn't a technical problem; it's a social one. If everyone feels responsible for being able to move stuff from develop to master, then the quality of the stuff sitting in the various develops goes up, and then you find you just don't need develop anymore.
- choult 13y ago
  Sorry, I don't quite get where you're coming from. In nvie's system, you just create a release branch from develop and then merge it back into master and develop when done. There's no other skill other than basic git-fu to do that. You can keep develop up to date with any changes from release branch periodically. The real complication with releasing is release management. But that's nothing to do with branches or even basic use of git, but one of engineering process in general. There's definitely no magic bullet for that.
  - geocar 13y ago
    > The real complication with releasing is release management. The real complication is developers that think "releasing" is somehow different than "development". When it's in master, then it's released. Whether you call that branch something else, or you use something other than a branch to indicate what is released, is completely irrelevant. The fiction that "develop" is some future point for master causes huge delays at best for large projects. In reality, "develop" is the hope or belief in some magic moment when the software is "good enough", and since it's someone else's job to decide whether it's "good enough", the buck is passed.
    - JanezStupar 13y ago
      I have no idea what your actual argument is. Whatever your problems are they have nothing to do with this particular git branching model. I suspect you have an issue within the culture you are a part of and no git branching model can fix that.
- MBCook 13y ago
  > If everyone feels responsible for being able to move stuff from develop to master, then the quality of the stuff sitting in the various develops goes up, and then you find you just don't need develop anymore. I can tell you that's not the way we do it where I work. Develop is basically the staging area right before you make a release branch (for final QA before deployment). Random feature branches do not get merged into develop by the developers, when we're going to do a release we decided which of the feature branches to pull in and add to the release. Only the few developers who actually prepare the releases merge things into develop.

by choult 13y ago

geocar 13y ago

The thing about develop is that only one (or two) people have the requisite skill in a large codebase to move stuff from develop to master. Transferring that knowledge is time-intensive and expensive. Scripts don't solve that problem because it isn't a technical problem; it's a social one. If everyone feels responsible for being able to move stuff from develop to master, then the quality of the stuff sitting in the various develops goes up, and then you find you just don't need develop anymore.

choult 13y ago
Sorry, I don't quite get where you're coming from. In nvie's system, you just create a release branch from develop and then merge it back into master and develop when done. There's no other skill other than basic git-fu to do that. You can keep develop up to date with any changes from release branch periodically. The real complication with releasing is release management. But that's nothing to do with branches or even basic use of git, but one of engineering process in general. There's definitely no magic bullet for that.
- geocar 13y ago
  > The real complication with releasing is release management. The real complication is developers that think "releasing" is somehow different than "development". When it's in master, then it's released. Whether you call that branch something else, or you use something other than a branch to indicate what is released, is completely irrelevant. The fiction that "develop" is some future point for master causes huge delays at best for large projects. In reality, "develop" is the hope or belief in some magic moment when the software is "good enough", and since it's someone else's job to decide whether it's "good enough", the buck is passed.
  - JanezStupar 13y ago
    I have no idea what your actual argument is. Whatever your problems are they have nothing to do with this particular git branching model. I suspect you have an issue within the culture you are a part of and no git branching model can fix that.
MBCook 13y ago
> If everyone feels responsible for being able to move stuff from develop to master, then the quality of the stuff sitting in the various develops goes up, and then you find you just don't need develop anymore. I can tell you that's not the way we do it where I work. Develop is basically the staging area right before you make a release branch (for final QA before deployment). Random feature branches do not get merged into develop by the developers, when we're going to do a release we decided which of the feature branches to pull in and add to the release. Only the few developers who actually prepare the releases merge things into develop.