re: How do you name your git branches? VIEW POST

FULL DISCUSSION
 

Overall, we use a fork-and-branch model. The rest depends on where in the project lifecycle things are and what our customer-dictates are.

Early in a project-lifecycle, there often aren't "issues", per se. It's usually "we need IOC by <insert date that's some fraction of the length of time that it likely ought to be>". It usually works out to a flow like:

  • initialize project in relevant git-service: do the initial commit so you can begin to branch; set up branch-protection on the base-branch(es)
  • Gen-off a "project-scaffolding" branch: add issue templates, MR/PR templates, contribution guides, CoCs, baseline test-configs (syntax linters for the languages/frameworks to be used), etc. Then merge that in
  • Start forking off IOC-supporting branches (naming is ad hoc)

Because we do work for multiple customers, things begin to deviate once the above is done. Some customers want issues managed in Jira. Some want issues managed elsewhere. Some are fine leaving them wholly contained within a given git service. Once we're to the point that there's discreet defined tasks that need to be individually coordinated and tracked, then we start using the customer-preferred tracking system. For tasks tracked wholly within the git service, we usually just do "Issue_<NUMBER>" to reflect the git issue-ID. If customer is mandating Jira, then we usually do "<PROJECT_ABBREVIATION>-<NUMBER>". For other issue tracking systems, we do either whatever's native to that system or whatever the customer asks.

...And if we're doing stuff on spec (anticipating a need for a customer or our own organization), then it's pretty much dealer'sdeveloper's-choice.

code of conduct - report abuse