4 ms·
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 de
by 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 agoDo 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 agoBut 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 agoCombined 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.