A battle is raging among software engineers around the world: which Git flow should our team use?
There are many options, including:
GitFlow
Git...
For further actions, you may consider blocking this person and/or reporting abuse
the best git flow I used is mixing rebase and merge on protected branches (master + release branches).it is quite simple:
2 another important points
btw in the link I provided they suggest to push -f to update your remote branch after rebasing. I think that --force-with-lease is safer (in 2013 the option wasn't available)
This also sounds like what we do at my company
Totally agree - there are tradeoffs with each, and it's really up to you and your team to figure out what is best for your codebase.
Also: I didn't realize there were so many named git worksflows! 🤣 Thanks for the roundup - I have some reading to do on some of those :)
At my previous job, we had this discussion as well, and the chosen branching model was Release Flow, as used by Microsoft. It has release branches and feature branches, optionally uses rebasing, and no merges. Main distinguishing feature is that hotfixes are committed to master and then elevated/cherry picked to the feature branch.
Our reasoning was as follows:
Hope this gives some more insight!
Git Flow - это проверенная классика и простая концепция. А потом если менять, то уж на GitLab Flow, где применяется усложнение в виде дополнительной стабилизации в pre-prod ветке.
Идея, что в develop ветке лежит самый актуальный код для разработки - очевидная и больше соответствует тем подходам в разработке, которые применяются до какого-либо флоу, что облегчает переход на неё с других CVS (Subversion, TFS), где логика поддержки релизов похожа.
Если начинаете внедрять методологию Git Flow - рекомендую презентацию на русском языке: medium.com/ruopsdev/git-flow-prese...
Там есть ссылки на плагины gitflow для IDE (Visual Studio Code, JetBrains IntelliJ IDEA, Atlassian SourceTree) и сравнение с GitHub Flow и GitLab Flow.
In my view the differences are miniscule, and the importance is communication.
Git is a Communication tool
Jesse Phillips ・ Dec 12 '18 ・ 2 min read
This basically leads to only one type of flow.
The specifics about release and patching comes from a need to update a specific commit. That specific commit can be tracked in many ways.
I don't think I'm following: "the differences are miniscule" but when "the importance is communication" it "leads to only one type of flow." The flow you suggest is completely different from several of the listed flows, so they don't seem to be "miniscule" differences and it seems like teams have settled on completely alternate approaches in their attempt to communicate. Help me understand what I'm missing.
(sorry more ramblings) If you don't rebase your working/feature branch, you don't care about communication (or your development is much more organized then mine).
If you stand up long standing branches, you must have large contribution teams with frequent support for your various releases, otherwise you're solving for a problem you don't have.
In the article it states that git flow doesn't use rebase, if you do no buddy will know. This thought that you can force someone to not do rebase is rediculous, but you can clearly enforce needing to rebase.
I was once on the camp that it didn't matter, rebase or merge, git will figure it out and combine changes. But I ended up in quality assurance and being able to clearly define what is change and why for each line of code is critical to a good review and understanding.
I take shortcuts, but if quality really is important, better orginizing or even eliminating the last 25 commits is worth it.
quoteinvestigator.com/2012/04/28/s...
My senior collegue :
Git/Hg flow is the worst, but if not flow then what?!
We brainstormed, gave a bunch of other "flows" and came to the conclusion that git/hg flow is indeed the worst, and we still are gonna use it...
Thanks for the very comprehensive list! I didn't know there were this many!
I dont have any experience with git flow. I have plan to use it but need more knowledge before implement to my repository. Your article give me new information that there are some git flow.