I actually thought GitHub Flow was more commonly used, as it's lighter-weight:
GitFlow considered harmful
21–30 of 342 posts
Re: GitFlow considered harmful
#22> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful"…
“Considered Harmful” Essays Considered Harmful
Re: GitFlow considered harmful
#23I think it greatly depends of the size of your team: if you're alone you have one branch, if you're two you may have 3 branches, each for one of you + master, if you're four you start to use feature-based branches..
It might be fun to compute the number of branches needed as a function of the number of devs in your team.
Re: GitFlow considered harmful
#24GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier.
The power of git is the ability to work in parallel without getting in each-others way. No longer having a linear history is an acceptable consequence. In reality the history was never linear to begin with. It is better to have a messy but realistic history if you want to trace back what happend and who did and tested what at what time. I prefer my code to be clean and my history to be correct.
I prefer to start with GitHub flow (merging feature branches without rebasing) and described how to deal with different environments and release branches in GitLab Flow https://about.gitlab.com/2014/09/29/gitlab-flow/
Re: GitFlow considered harmful
#25I second the feeling of GitFlow being over-engineering: http://blog.talles.me/that-git-flow.html
Absolutly agree, to much complexity.
Re: GitFlow considered harmful
#26I think he makes a valid point about how it's not necessary to have both develop and master if you use tags. On the other hand, I think the `--no-ff` merges is what git-flow got right. The separation of features into their own branches is useful. It's basically about grouping related commits together. You can always render the history in a way that looks prettier and even if you can't--the history doesn't need to look pretty, the final product does.
Re: GitFlow considered harmful
#27Anyone else fed up of articles using "considered harmful" in the title? Especially when it's just that the author doesn't like that thing.
Yup.
Re: GitFlow considered harmful
#28The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct.
That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness"
- branches: Work in progress.
- develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world.
- master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests.
As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...
Re: GitFlow considered harmful
#29Most of the merges in his first pictures aren't even fast-forwardable, so his complaint about no-ff seems.. weird?
You should still rebase your feature branch on top of whatever you're merging into whenever you can, even if you're using git-flow. That's just common sense. When you do, your history looks almost the same as in his 'pretty graph', there's just one more 'link' back to the previous feature merge.
The advantages of this additional context are important. Firstly, you can get a compressed view of only the features that were merged (without detailed commits) with something like `git log --first-parent`. I guess the only way to do that in OPs approach is `git log | grep 'SPA-'`? Rather... unreliable.
Using no-ff also means you don't have to do the silly thing of putting your issue name / branch name in every commit title. Titles are pretty short already, having to allocate ~10% of it to tracking the name of the branch is just wasteful. With no-ff it's obvious which feature the commit is for (the branch name in the merge). If your tool fails to present that in a reasonable fashion, that's disappointing, but the data includes this context and that's the most important thing.
As to the master/develop split, yeah I could be convinced it's unnecessary. Still, I think it's convenient to have a clear separation of 'this code is in production', 'this code is in development'. If you just make a release branch then merge it into develop, you have to know the exact tag before being able to find the latest release. 'master' being the alias for 'latest release' is fine.
Re: GitFlow considered harmful
#30I never used gitflow so I could be wrong but the main problem with logging seems to be this:
Gitflow thinks about branches as lanes. Git branches are actually labels. What's the difference? In the gitflow model every commit belongs (implicitly) to a branch (or a lane). Git branches don't work that way. One could actually implement "lane" as an additional commit metadata and tweak git-log (and other git utilities) to always show lanes in straight lines in the graph.