It sounds way less offensive to those who decry the original terminology's problematic roots but still keeps its meaning intact.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 years ago* (last edited 2 years ago) (3 children)

In our environment Prod is only a holding area, the change/feature/bugfix is already approved for production, once the change is documented then the merge happens into main and Prod is consumed.

Our "working" branches are ephemeral.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 2 years ago (2 children)

    Seems like what we use “RC” for (Release Candidate)

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago* (1 child)

    Yeah, we're trying to avoid a lot of hanging branches with no documentation so we try to prune as much as possible. So we built pruning and documentation into the workflow of the pipeline.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 years ago

    Great! The best I’ve been able to do is document a best practice to default to deleting the source branch on merge. I actually just now finished writing a script to list all repos with various details including the setting about deleting source branches on merge. I’ll talk to a few teams about it, then see if I can get management approval to set it for all repos (you can click to override in the merge request so it seems harmless)

  • source
  • parent