Custom git-flow workflow

As an example, I made my wrote my own workflow, git-wave. (Naming things is hard, leave me alone.)

I don't want to get into blog post level of detail about it, but long story short, if I could link the smartgit UI to a script directory, or some metadata, or something configurable, it would remove the step of jumping out of smartgit to perform workflow operations.

The support wouldn't have to be cross-platform, eg, just execute a linked script.

You could also offer a fully customisable view, via some configuration script, or something, but I can see that getting complex fast. (Read a json file, and configure the git-flow UI from that)

It would be a ton of work, and probably only used by the likes of me.

Even a programmatic API would be amazing.

I'd be happy writing a plugin if you had a plugin system.

Now that I think about it, you should also add a plugin system.

Granted, that might be a bit hard with the obfuscation layer... :/

Scratch that.

TL;DR: Giving some control over the git-flow UI would be appreciated.

Could you please describe in more details why you want to customize the work-flow, what you don't like about the current (default) work-flows?

It's not personal against git-flow, or smartgit's implementation of it, but it's more of a problem with our development cycle and projects, and how they don't fit perfectly into a git-flow model.

We don't have the resources to launch automated tests on all feature branches, nor do we have the time to deal with starting up our projects for each and every feature merge.

Which means we're going to be testing a couple of features at a time, and some of those features might be buggy, or something, which means we need to reopen the issue responsible for that.

Now we've got an unfinished ticket on the develop branch, we could revert it, but the git-flow model doesn't really have support for that, so that means neither does smartgit.

Which means stepping in manually.

Some of us are more than comfortable within a command line, others less so, hence a GUI.

However, we quickly found while trial testing various clients and a couple of our lesser talented individuals, it generally ended in less than desirable outcomes.

So, it would probably just be quicker to give them a simple interface, rather than to teach them how to use git, because before all of the git stuff, we used CVS.

Which is almost as simple as it gets, but it has a host of other terrible problems, hence the move.

But because it was simpler, and the company had dealt with it for a long time, everyone had forgotten or gotten use to the problems, so whenever anything pops up in git, it can lead to some unfavourable backlash.

I had the idea of making it a simple process, and having used smartgit for personal use for a couple of years now, I immediately thought of it, but due to our requirements, it got shoveled onto the wishlist instead.

We haven't rolled out the git model, it's more or less still in the planning phase, with only a couple of our smaller internal projects converted.

To test out the GUI idea, I threw together a workflow client with JavaFX and JGit, and does nothing but manage the workflow.

People current use their IDE to manage the version control, whether that be intellij or eclipse is dependent on the developer.

I know we'd be happy to switch to smartgit if we had support for a custom workflow.

Side-note:

The workflow itself has a complex mode and a simple mode.

The complex mode is too much to get into here, but the simple mode is pretty straight-forward.

Fork a feature branch from master, develop said feature, merge into a develop branch, the develop branch will be tested throughout the day, once the feature passes, we can merge into master.

Once we perform a release, we simply create a tag on the master branch, and repeat.

The branches don't diverge, because I monitor the repo, and the commits will always end up on master.

There's a couple of problems with the simple version, firstly, you don't have the latest codebase.

While this could be a problem, it's only a problem if you work in the same area of code.

We have fairly large projects, and not a lot of developers, so we rarely hit that.

However, that being said, we have had a couple of features that extend other features that were still being developed, so the solution to that is to fork from the feature.

This is wear the UI I wrote comes in, when you start a new feature, you can start a new feature from master, or from one or more already existing feature branches.

The program remains aware of this, and you won't let you checkout the feature onto master until the features that it depends on are also on master.

That's the gist of it.

If it's not clear, I'll see if I can whip up a graph.

Well, I assume you know that you can always hook menu items command line scripts in SmartGit (Tools menu) -- This is not through the built-in GitFlow menu. I do not know if there is a way to automate the configuration of the Tools menu to make it easy for all employees to install your scripts and if there are enough options to do what you want, but it's been pretty good for us.  It will not be as customizable as your own GUI tool, but you do get all the SmartGit niceties.

I didn't, and it seems quite useful.

The only thing lacking would be a dialog asking for user input.

If that was implemented, I'd be happy to start exploring the uses of smartgit within the company.

Would be awesome if we could configure the toolbar with a dropdown of the commands.