Basic question about Crucible workflow and git branch strategy

Michelle Eshow

We're planning our migration from ClearCase/ClearQuest (!) to the Atlassian stack (except Stash, which is coming soon) and git. I have a basic question about how folks manage the number of branches that proliferate in the main repository when using Crucible. That is, we do our development on Issue-named branches. My understanding is the developer has to commit and push their branch to the master repo in order for Fisheye/Crucible to see it and present it to a reviewer. In response to code reviews, the developer has to commit and push a new change set on that branch to the master repo, for the reviewer to see the reworked code.

So over time it seems there will be many branches that appear in the Crucible commit graph browser - one per issue with possibly multiple commits per branch. For us there will be hundreds per year. And each one might have multiple commit events.

So I'm wondering how other customers clean up their git histories or otherwise handle this. Do you get rid of old branches (with git push origin --delete branch_name)? Do you automate that? Or is there a more elegant way to keep old branches from showing up in Crucible? Maybe this is more of a git question but it seems the Crucible model forces branches to be pushed and not remain local to the developer.

Michelle

Stefan Saasen

So I'm wondering how other customers clean up their git histories or otherwise handle this. Do you get rid of old branches (with git push origin --delete branch_name)? Do you automate that?

Hi Michelle,

In my opinion that's largely up to the team and the procedures/policy the team likes to follow. The Confluence team for example uses issue branches and cleans them up regularly. We've automated that using Bamboo and the Bamboo jobs deletes all branches:

a) that have been fully merged into the main line branch (so no commit is lost)

b) where the last commit is more than 30 days ago (so presumably the developer who was working on that branch has no intention of adding more changesets to that branch.

Logging those deletions allows us to recreate a branch if necessary.

Hope this helps.

Cheers,

Stefan