Hotfix and Support branches

[dkirrane]

display gitflow hotfix and support branches

[Teun]

Could you elaborate a bit? The chart already displays hotfix branches (in the same part of the graph as release branches). I'm not sure what support branches are. Can you provide a link?

[marcos-software]

Hi Teun,

what about bugfix branches ? We're using stash (already bought your add-on on atlassians marketplace) and have really much bugfix branches. It seems, that your add-on show this as "unrecognized" branches (with black color) ? Can you add the branches into the grafics too ?

Regards, Marc

[Teun]

Hi Marc, Yes, that is something I'd definitely want to offer. Could you send me a link to a description of bugfix branches as they are defined by gitflow? This issue suggests that they shouldn't exist as a separate style.

Maybe you can help me out sketching what you would expect in the chart. If you can send me a repo state that uses bugfix branches as you think is proper and then describe to me what you would expect in the chart, I can have a try. You can send me the data I need by opening your repo in your browser and then hitting Ctrl+Shft+} this will open a text area with JSON ready to copy.

[marcos-software]

Hi Teun,

I'm sorry, the project isn't public so I cant send you a repo link. Stash (and so also Jira) creates by default 4 branchtypes: Bug, Feature, Hotfix and Release. A descirption is shown in the attached image (but in german, our stash is localised ;-) ).

Were using this 4 Branchtypes, the prefixes are:

bugfix/ feature/ hotfix/ release/

In the second attachment you can see a suggestion / example, how I would love to have it look like

[Teun]

If I get the German right, you would expect the bugfixes to branch off from release branches, not from develop, right? So the order from left to right would be: master - hotfix - release - bugfix - develop - feature

Or am I misinterpreting something?

[marcos-software]

No, hotfixes (quick but important failures) branch off from release branches, bugfixes (long time taking and less important problems) branch off from develop branch.

PS: Your German was right, but we use it in this way ;-)

[marcos-software]

I updated the suggestion image, maybe it's now better understandable

[Teun]

That's not what your screenshot from Stash says. The idea here is the release branches go from develop to master and give you some time to stabilize. If you find a problem in master that cannot wait for the next release, you create a hotfix, branching off master and merging back to master. A bugfix branch (which is not part of the original gitflow description by Vincent Driessen, but a common practice) is to a release branch what a feature branch is to develop.

I don't want to be religious on this, but I don't want to go against the standard naming and practices.

[marcos-software]

Well, the only changes between our usage and your description is one "level". We have 3 release branches we're mergin on it (from develop) to let the buildserver (Bamboo) automatically do some tests, obfuscations, signing and deplay the release on different updatechannels (so the customer only say in the application "please give me all major updater" or "please give me major and minor updates"). So, if merge from develop to the nightly build (well, Bamboo does this automatically at 2 am) it generates automatically an update with all needet information on the special update channel (branch: release/nightly -> updatechannel: nightly build, branch: release/minor -> updatechannel: minorbuild, branch: release/major -> updatechannel: major). Our masterbranch is more like a backup not used on daily work ;-)

You wrote: "release branches go from develop to master" -> we're doing it exactly like this, but have more than 1 release branch (think of it as "nightly" and "minor") and our (daily using) master is the third release branch -> major (because releases are generating updates in bamboo and thats the only way customers can get new implementations / fixes).

You wrote: "If you find a problem in master that cannot wait for the next release, you create a hotfix, branching off master and merging back to master."

Well thats also what we do, but our master are (like i specified above) the release branches. It goes from release and comes back to it.

Your wrote: "A bugfix branch is to a release branch what a feature branch is to develop." Well, we handle it a bit other. bugfixes and releases, both have to come from (and go back to) the big develop, because both have do be developed and approved like an normal develop (and so the routines in bamboo are exactly the same). The difference is not in their implementation, its in their functionality. Features add features, Bugfixes solve problems (the kind of problems that are not so important but mostly long-time-taking - not like hotfixes, which are important and so come from our release branches and goes back to it).

[Teun]

Right. What I take from this is that what Atlassian calls bugfix branches, you call hotfix branches and you have two kinds of feature branches coming off develop: the ones that contain new functionality and the ones that fix broken functionality (I actually agree with you that features and bugfixes are different things).

I have to give this some thought and figure out a way to allow you to have the setup you'd like without going too far of the described naming conventions.

[marcos-software]

perfect (y) thanks a lot!

[Teun]

What I am going to implement is the following:

• we will not have more colors and zones. I think it is preferable to have only 4 colors: master (one line), develop (a few lines, because develop doesn't always grow linearly), release branches (between the master and develop line, including both release/1.0 and hotfix/1.0.001) in yellow and feature branches to the right of develop.
• apparently, Atlassian advocates having yet another type (bugfix branches, working off a release branch) and some teams (like the other posters in this issue) use yet other types, like support branches.
• in the implementation of this issue, I will not make more 'types', but will allow users to specify regular expressions to force their custom branches into the releases zone or the features zone. By default, we will put 'bugfix/*' into the releases zone and all others into the features zone.

[richardp-au]

What about having a few custom types, where the user can configure a regex and a colour, and possibly also control the order of all types. You could even go as far as making all types configurable this way and just providing standard defaults. This would then allow everyone to configure it to suit their specific workflow.

For example, in our case, we have another type of branch for UAT which is somewhat like a release branch but it merges back into develop. While I could simply treat them as feature branches, they do have a more specific purpose so I'd prefer to be able to colour them differently.

[Teun]

@richardp-au : I understand that this sounds like an easy and obvious generalization. However, what I do in this library actually is very non-generic. The problem with git is that alle hosts and all branches, be it remote or local, be they named "develop" or "8818-my-whim", are equivalent. The algorithm relies on a few hard coded names (that are configurable), but more importantly on a number od pattern that appear when you follow the git-flow workflow.

If you think you can generalize the algorithm, feel free to try. The code is publicly visible and if you want, I'll license it under an open-source license if you manage to do so.

[remie]

@Teun : by closing this issue, does this mean that version 1.1.0 of the add-on is ready to be released?

[Teun]

No, I guess I shouldn't have closed that. I think it is completely implemented, but testing in the context of Stash is still not done.

[remie]

The add-on has been updated as is now available on the Atlassian Marketplace. It includes the releaseZonePattern regular expression option and has the latest version of the JS library.