i asked my senior "why we need a develop branch" and his reply was "-_-" , literally an emoji.

Ok ,well this might be a stupid question, but i have been in this organisation for 6 months and all this time these guys have not been able to make a proper release. either they miss commits while cherry picking, or they end up reverting stuff, or they are delaying the releases due to QA disapprovals, backend issues or management issues.

i proposed a simpler vcs :

1. `uat` is the source of truth
2. for every release we create a temporary branch `release-x.y.z` from `uat`
3. then we develop every feature in a branch cut from `uat` as `feat-abc`, code in it , and merge it back to `release-x.y.z`
4. finally we merge `release-x.y.z` into `uat`

where is develop branch supposed to be cut?
which branch is supposed to be cut from develop?
which branch is supposed to merge into develop?
where is develop supposed to be merged?

no one has answers to these fucking questions. but still they wanna confuse the whole team of 15+ android and ios devs about how to use which procedure

fml :/

  • 10
    - main
    Production copy of the code base, at ANY point in time this branch must be able to replace production code at the drop of a pebble.

    - UAT
    Stable code that can be tested by business users and should be deployed in a production like environment, used as last line of defence before merging to prod

    - dev
    The unstable branch the dev(s) are working merging features into and ensuring merge conflicts are caught early.

    - feature/xyz
    The branches of mayhem, where new features / bugs / hot fixes / whatever you want are being developed.


    Where this gets complex depends on the pipeline or deployment strategy being used,
    Features are typically cut from either UAT, if it's for extending something in progress or has a dependency on something In progress, or main if it's a new feature.

    How you move up the branches and environments could be 1 at a time which leads to waterfall deployments, or feature to dev, feature to UAT, feature to main if the features are small enough and lack dependencies.


    At least that's how I operate the madness.
  • 5
    See trunking + git flow
  • 2
    You can think of whatever convention u want to implement for your git branches.

    If chaos is going to ensue, it will ensue and nothing can stop it.
  • 1
    The only topological difference between your flow and the existing one is that it includes regularly branching off of one state with the intent of merging into something else, which makes all merge conflicts 100x worse. Other than that you're just shuffling labels.
  • 1
    I think the problem is different entirely. How many releases were attempted in this 6 month period?
  • 7
    Version tracking strategies differ from org to org, but your senior should never treat you like that and always be open to new ideas.
  • 1
    @C0D4 the one thing that really trips me up is the DB migrations. Realistically, every release would be forced to have scripts ready to go back and forth, but for my tiny company it just doesn’t seem to be worth the effort.I want to implement it, but with us releasing new stuff every 2~4 weeks I cannot see it happening any time soon.
  • 1
    @lorentz you are correct about branch getting cut from one brwnch and merging into another. it has a high probability of getting conflicts but those can be resolved by taking a pull of the release-x.y.z branch.

    this is intentionally done so that every feature brsnch is just [old stable code + 1 new feature code] and not [old stable code + multiple new feature code that are still in testing]

    if anyone is feeling a bit rowdy, then they can directly cur a branch from release-x.y.z branch too
  • 0
    @dotenvironment I think normally dev testing should be robust enough to allow building other features around the existing code. QA should not result in structural changes.
  • 1
    The fewer long lived branches you can get away with the better.
    If you don't need a branch for a testing/staging environment (cool pipelines can use PR/MR) and you don't need a place to collect features for a release you don't need a develop branch.
    It just introduces overhead.
Add Comment