3 ms·

I don't understand how people find GitFlow to be complex or slows them down. If feature branch is long lasting just merge regularly from develop branch so you d

by ssijak 9y ago

I don't understand how people find GitFlow to be complex or slows them down. If feature branch is long lasting just merge regularly from develop branch so you don't end up with a tough merge when the feature is finished. Apart from that, just trust your devs. People are not stupid, gitflow process is sane and simple, nobody will start pushing to master like crazy if you allow merges without pull reviews. If you dont trust the devs to do the simple tasks right, do you trust anybody in your organisation? Do you check every step/change your devops/sysadmin/dbadmin make?

m12k 9y ago
The problem with GitFlow is that it takes a fairly common and sane master+feature/bugfix-branches approach and makes it needlessly complicated with the whole develop+master branch split and some dubious recommendations like 'git merge --no-ff myfeature'.
- charrondev 9y ago
  Do you have any further details on this? The tabs always looked weird to me but I don't know why. We practice "gitflow" at my work, except we deviate from it to fit or workflow better. We have feature/fix branches and a master branch that we all use on our dev machines every day, we never ship our master branch though, we ship versioned releases which get backplate of bug fixes as needed. We have hundreds of clients on their own clusters and we stagger new releases to the clusters in order of customer priority. We try to ensure PRs are well tested before merging, bit of minor issues crop up on master we file a bug and sprint it ensure it is fixed before the next release (and generally by whoever did the initial work that caused the issue).
- Spivak 9y ago
  But preserving merge commits isn't a dubious recommendation, it's just about creating a consistent history. One could consider it a stylistic choice but, at least for me, it does make the history more readable.
  - bonesss 9y ago
    Combined with squashing and rebasing git flow leaves a very nice history... I can imagine if you're slamming a bunch of uncurated commit messages along with lots of merges you're gonna see a chaotic history. A consistent history is a must-have with a distributed team, IMO. GitFlow's tooling is nice in that context to enforce consistent operations across environments and teams where not everyone is 100% perfect with Git.

by ssijak 9y ago

m12k 9y ago

The problem with GitFlow is that it takes a fairly common and sane master+feature/bugfix-branches approach and makes it needlessly complicated with the whole develop+master branch split and some dubious recommendations like 'git merge --no-ff myfeature'.

charrondev 9y ago
Do you have any further details on this? The tabs always looked weird to me but I don't know why. We practice "gitflow" at my work, except we deviate from it to fit or workflow better. We have feature/fix branches and a master branch that we all use on our dev machines every day, we never ship our master branch though, we ship versioned releases which get backplate of bug fixes as needed. We have hundreds of clients on their own clusters and we stagger new releases to the clusters in order of customer priority. We try to ensure PRs are well tested before merging, bit of minor issues crop up on master we file a bug and sprint it ensure it is fixed before the next release (and generally by whoever did the initial work that caused the issue).
Spivak 9y ago
But preserving merge commits isn't a dubious recommendation, it's just about creating a consistent history. One could consider it a stylistic choice but, at least for me, it does make the history more readable.
- bonesss 9y ago
  Combined with squashing and rebasing git flow leaves a very nice history... I can imagine if you're slamming a bunch of uncurated commit messages along with lots of merges you're gonna see a chaotic history. A consistent history is a must-have with a distributed team, IMO. GitFlow's tooling is nice in that context to enforce consistent operations across environments and teams where not everyone is 100% perfect with Git.