These tools are good if you have to use Git-Flow. But I would advice against it. In every single company/project I've worked on that's used Git-Flow, pretty much everyone eventually agreed that it was overkil and needlessly complicated. Something like GitHub Flow is much simpler and straight forward, and typically what we've migrated to, or at least wanted to migrate to. Often such decisions need to go through management, which doesn't always go well due to GitHub Flow not having any rules for versioned releases or a hard-copy specification document among other things.
This is where something like Git Common-Flow [1] tries to fill the gap. Full disclaimer, I'm the author of Git Common-Flow. It was born out of my frustration after one too many arguments about Git-Flow vs GitHub Flow and what GitHub Flow lacks. Common-Flow is essentially GitHub Flow with the addition of versioned releases, optional release branches, and without the requirement to deploy to production all the time.
What's overkill about developing features in a dedicated branch, isolated from everyone else's commits? What's complicated in creating a branch, committing to it, and then merge the changes into the development branch?
The issues I have with Git Flow isn't feature branches, it's the develop branch, and the whole crazy merge dance between develop, release, and master branches. It doesn't provide much benefit and more often than not causes confusion and and problems.
What I'm in favor is is GitHub Flow or anything very similar to it, which just has master and feature branches, nothing else.
> The issues I have with Git Flow isn't feature branches, it's the develop branch
What's wrong with that?
> and the whole crazy merge dance between develop, release, and master branches.
I really don't understand your problem. What's so crazy about separating a stable from an unstable branch, and avoiding to push unstable features when you're preparing a new release?
> It doesn't provide much benefit
I see you never were forced to work overtime just because an overzealous manager decided to merge into a release an unstable feature that ended up triggering crashes in a client.
Do you know what's a good way to avoid that problem? Keeping a stable branch, and not confounding a release with the current state of the development branch.
Whenever I see these sort of complains it appears that the only people who complain about the need to organize a project around separate branches dedicated to track main, release and development branches are people who don't have much (if any) experience working on real-world software development projects.
I have no issues with separating the latest greatest development work from production ready code, I just think the way Git-Flow does it is needlessly complicated with multiple points of redundancy.
For example, the master branch is only ever updated when a release (or hotfix) branch is merged in to master, at which point you also tag master with the release version. Why do you need both a tag and a branch pointing at the latest release?
Instead of ignoring tags, why not use only tags to define releases? At which point you can get rid of master as defined by Git-Flow, and rename develop to master, so you just have a master branch. If the release process (QA, etc.) is lengthy, by all means create a release branch from master to avoid a change freeze. When ready for release, create the release tag on on the release branch and merge it back into master if needed.
Also the whole "feature/" and "hotfix/" prefixes on branch names feels pointless. Why not just call them all "change branches"? Anything that changes stuff, is a change branch. And how about we enforce descriptive names on branches like "add-2fa-support", "fix-login-issue", "update-font-awesome", and "change-search-behavior"? No prefixes needed and yet the purpose of the branches are perfectly obvious.
If I'm not sounding like a complete idiot here, please do have a look at Git Common-Flow [1]. I'm genuinely interested in hearing your feedback about it. Again, full disclaimer, I am the author of Git Common-Flow.
> Assumes nobody's changes ever collide or conflict with each other.
I don't believe that anyone using any VCS expects every single commit to be free from "conflict" or "change collision".
In fact, the whole point of using VCS is that "conflicts" and "change collisions" are a given, thus there is a need to use a specialized tool to manage merges and handle conflicts.
> Introduces a fear of refactoring
On who? They have the exact opposite effect.
Have you ever actually used any version control system?
My point was that any branching strategy will necessarily introduce an integration delay. Instead of merging to master every hour or so, the delay is measured in days. The longer the gaps between merges the larger the change set, the greater the risk and impact of merge conflicts.
And, yes, I have! SourceSafe, CVS, StarTeam, Subversion, Perforce, ClearCase, PVCS, Mercurial and Git in (roughly) chronological order by my reckoning. Thanks for asking.
If you're that worried about merge conflicts, isn't the real problem that you haven't refactored enough for SRP? If two people are working on different things, they probably shouldn't be editing the same code.
This is where something like Git Common-Flow [1] tries to fill the gap. Full disclaimer, I'm the author of Git Common-Flow. It was born out of my frustration after one too many arguments about Git-Flow vs GitHub Flow and what GitHub Flow lacks. Common-Flow is essentially GitHub Flow with the addition of versioned releases, optional release branches, and without the requirement to deploy to production all the time.
[1] https://commonflow.org/