GitFlow
-
We have a small development team with 8 developers working in C#, we are using GIT and have TeamCity running on the builder. The system we use at the moment is known as Trunk Based Development[^] Some of my colleagues think that the "GitFlow" system would be better: A successful Git branching model » nvie.com[^] Personally I have my doubts about GitFlow, despite the hoorah stories that can be found on the web. I think it will cause a lot of merge conflicts, and it will make life harder especially for developers that are not very adept at using GIT. Besides when even Google successfully uses "Trunk based development" with thousands of developers, why couldn't we ? Anyone tried GitFlow, and what is your opinion about this ? [Edit] found this interesting article Git: How I use it and Why I don’t use GitFlow – Matthew DeKrey – Medium[^]
-
We have a small development team with 8 developers working in C#, we are using GIT and have TeamCity running on the builder. The system we use at the moment is known as Trunk Based Development[^] Some of my colleagues think that the "GitFlow" system would be better: A successful Git branching model » nvie.com[^] Personally I have my doubts about GitFlow, despite the hoorah stories that can be found on the web. I think it will cause a lot of merge conflicts, and it will make life harder especially for developers that are not very adept at using GIT. Besides when even Google successfully uses "Trunk based development" with thousands of developers, why couldn't we ? Anyone tried GitFlow, and what is your opinion about this ? [Edit] found this interesting article Git: How I use it and Why I don’t use GitFlow – Matthew DeKrey – Medium[^]
I use Sourcetree and have the gitflow enabled. ([Gitflow Workflow | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)) It works pretty well for our team of 6. I think feature and release branches are definitely better, for stability. We work on feature branches which get merged to dev, which goes to QA, which then gets into master via releases. I mostly work on my own project or separate section, so I haven't had much conflicts. I think the amount of conflicts will be determined by how much overlap there is - how the work is divided and how modular the app is. What is nice about using this flow is that our build servers are automated for things like releases and deployments.
-
We have a small development team with 8 developers working in C#, we are using GIT and have TeamCity running on the builder. The system we use at the moment is known as Trunk Based Development[^] Some of my colleagues think that the "GitFlow" system would be better: A successful Git branching model » nvie.com[^] Personally I have my doubts about GitFlow, despite the hoorah stories that can be found on the web. I think it will cause a lot of merge conflicts, and it will make life harder especially for developers that are not very adept at using GIT. Besides when even Google successfully uses "Trunk based development" with thousands of developers, why couldn't we ? Anyone tried GitFlow, and what is your opinion about this ? [Edit] found this interesting article Git: How I use it and Why I don’t use GitFlow – Matthew DeKrey – Medium[^]
My biggest issue with git flow is the 'Release branches must merge back into master and develop'. When you need to support previous (and long running) releases, it makes zero sense. Git flow, I think, works only if you have the kind of software that can always be upgraded to the latest version, no matter what, and you don't do any bug fixing or small functional additions to prior releases. So you have only one 'master'. Think of MySQL bugfixing 7.x.y (release branch) and then merging that bugfix into the latest development (8.0.x). That bugfix might be in code that even doesn't exist anymore.
-
My biggest issue with git flow is the 'Release branches must merge back into master and develop'. When you need to support previous (and long running) releases, it makes zero sense. Git flow, I think, works only if you have the kind of software that can always be upgraded to the latest version, no matter what, and you don't do any bug fixing or small functional additions to prior releases. So you have only one 'master'. Think of MySQL bugfixing 7.x.y (release branch) and then merging that bugfix into the latest development (8.0.x). That bugfix might be in code that even doesn't exist anymore.
We struggled with that in the past when we were using SVN. For supporting bugfixes on older versions you could make separate branches in GIT for each release (if your CI system supports that kind of thing). It seems Bamboo and TeamCity do support it :-\ I think I would prefer to only create the separate branch when the need for a bugfix arises, otherwise it makes things a bit messy.
-
We have a small development team with 8 developers working in C#, we are using GIT and have TeamCity running on the builder. The system we use at the moment is known as Trunk Based Development[^] Some of my colleagues think that the "GitFlow" system would be better: A successful Git branching model » nvie.com[^] Personally I have my doubts about GitFlow, despite the hoorah stories that can be found on the web. I think it will cause a lot of merge conflicts, and it will make life harder especially for developers that are not very adept at using GIT. Besides when even Google successfully uses "Trunk based development" with thousands of developers, why couldn't we ? Anyone tried GitFlow, and what is your opinion about this ? [Edit] found this interesting article Git: How I use it and Why I don’t use GitFlow – Matthew DeKrey – Medium[^]
Please check GitHub Flow, used by Github. Simpler than Git Flow. GitHub Flow – Scott Chacon[^]
J.Motta
-
Please check GitHub Flow, used by Github. Simpler than Git Flow. GitHub Flow – Scott Chacon[^]
J.Motta
Yep, that looks a lot like Trunk Based Development[^] That's my favourite too ;)
-
We have a small development team with 8 developers working in C#, we are using GIT and have TeamCity running on the builder. The system we use at the moment is known as Trunk Based Development[^] Some of my colleagues think that the "GitFlow" system would be better: A successful Git branching model » nvie.com[^] Personally I have my doubts about GitFlow, despite the hoorah stories that can be found on the web. I think it will cause a lot of merge conflicts, and it will make life harder especially for developers that are not very adept at using GIT. Besides when even Google successfully uses "Trunk based development" with thousands of developers, why couldn't we ? Anyone tried GitFlow, and what is your opinion about this ? [Edit] found this interesting article Git: How I use it and Why I don’t use GitFlow – Matthew DeKrey – Medium[^]
My company uses gitflow for several different projects (several different git repos) with teams of varying sizes, anywhere from 3 - 20 developers (so, yes, relatively small). Gitflow works well for us and, for the most part, I fail to see any significant differences between gitflow and the others mentioned here. I'm familiar with the "successful Git branching model" article but I prefer Atlassian Gitflow Workflow. In my opinion, it's simpler. Regarding the complaints about gitflow, either we've subconsciously tailored gitflow to meet our needs or two articles linked above are wrong about gitflow (or I am wrong about gitflow). Two key claims made in those articles are 100% inaccurate (there are probably more, I only skimmed): 1. "Another big difference from git-flow is that we push to named branches on the server constantly." -- yeah, we do that too with gitflow and, in fact, Atlassian's page says "Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration". 2. "The other gap that I’ve found with GitFlow is that it doesn’t provide support for old release versions." -- Huh? I don't think so (e.g.
git checkout v1.2.3wherev1.2.3is a tag for release 1.2.3 and you are currently on release 10.11.12) and then patch your code and releasev1.2.3.1. Other complaints about gitflow are more about "problems" with dev-process or company-culture: 1. "Long-running branches" is a relative term. I agree "long-running branches" are a very bad thing but branches that last a week or two are fairly common on our smaller teams but I suspect larger teams might reasonably consider these to be "long-running branches". 2. We do code reviews (not just merge requests) so would rather not tolerate the overhead and interruption involved in some strange policy that "all team members commit to trunk at least once every 24 hours". 3. The projects I'm working will never scale to 25000 developers on a monorepo so a flow technique that scales to that level is not a selling point for me. Bottom line is that all of these flow techniques work and all of them can be customized to fit your needs. What's more important is that you choose *some* flow technique, then decide on the "official" documentation, and then point all current and future devs to that documentation. -
My company uses gitflow for several different projects (several different git repos) with teams of varying sizes, anywhere from 3 - 20 developers (so, yes, relatively small). Gitflow works well for us and, for the most part, I fail to see any significant differences between gitflow and the others mentioned here. I'm familiar with the "successful Git branching model" article but I prefer Atlassian Gitflow Workflow. In my opinion, it's simpler. Regarding the complaints about gitflow, either we've subconsciously tailored gitflow to meet our needs or two articles linked above are wrong about gitflow (or I am wrong about gitflow). Two key claims made in those articles are 100% inaccurate (there are probably more, I only skimmed): 1. "Another big difference from git-flow is that we push to named branches on the server constantly." -- yeah, we do that too with gitflow and, in fact, Atlassian's page says "Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration". 2. "The other gap that I’ve found with GitFlow is that it doesn’t provide support for old release versions." -- Huh? I don't think so (e.g.
git checkout v1.2.3wherev1.2.3is a tag for release 1.2.3 and you are currently on release 10.11.12) and then patch your code and releasev1.2.3.1. Other complaints about gitflow are more about "problems" with dev-process or company-culture: 1. "Long-running branches" is a relative term. I agree "long-running branches" are a very bad thing but branches that last a week or two are fairly common on our smaller teams but I suspect larger teams might reasonably consider these to be "long-running branches". 2. We do code reviews (not just merge requests) so would rather not tolerate the overhead and interruption involved in some strange policy that "all team members commit to trunk at least once every 24 hours". 3. The projects I'm working will never scale to 25000 developers on a monorepo so a flow technique that scales to that level is not a selling point for me. Bottom line is that all of these flow techniques work and all of them can be customized to fit your needs. What's more important is that you choose *some* flow technique, then decide on the "official" documentation, and then point all current and future devs to that documentation.Thanks, that's a nice explanation on the Atlassian site, but I think we will be holding on to "Trunk based development" for the moment.