Comments by "Edward Cullen" (@edwardcullen1739) on "Git Flow Is A Bad Idea" video.

They needed complex merge strategies because of poor architecture?
3
@grigoriypiskun6091 Forking is for public projects. In a business context, Forking is ALWAYS the wrong thing.
3
@TARJohnson1979 With Tom on this. History only tells you how you got here, not how to go forwards (though, it may offer hints). People put too much stock in "history". I've had devs reject things like whitespace/line ending normalisation because it "breaks the history". Their logic being "we should perpetuate BAD, unreadable code, for the sake of history". (Also, let me introduce you to the diff option that ignores whitespace differences...) Ironically, the argument being put forward is both "history is important" and "history isn't important"; you want a *good*, "clean" history, but you ALSO think squash commits - that erase history - are a GoodThing™. My sense is that, in practice, there are 2 things that really matter: diffs between points-in-time (one of the few strengths of Clear Case IIRC) and blame... Sorry "annotation". In short, I think people worry too much about this aspect of VCS. Write your code, make sensible commit comments and let the weirdos (like me) sweat over the minutiae of VCS management 😂
2
Right, okay, I see. I replied to OP about his support for GitFlow, because branching is a way to handle merge conflicts. When you replied to my generalisation, that constant merge issues indicates poor architecture, I missed that it was a "there's no blanket rules" (which I'd taken as self-evident/had said already - maybe on a different thread, so... I plead "Senior Moment" 😅) Because I just assumed high level of participants, I assumed me saying "there's exception to different rules...
2
Yeah, I looked at Gitflow when it was new and it was OBVIOUS to me - as a nearly fresh graduate - that it was overly complex and would result in more effort to manage than KISSing it... Gitflow is antithetical to CICD, I'm completely with Dave. Gitflow - or something like it - can be appropriate, but only as a stepping-stone to doing things better. Managers like Gitflow, because "it's a thing with a name", but since when did managers actually understand version control?
1
If you have large amounts of merge conflicts, then you have an architectural problem. Fix the problem, instead of applying a sticking plaster to it. (Dave has already done a vid discussing this...)
1
@dafyddrees2287 Refactoring large amounts of code to implement a new feature sounds like an architectural change... So it's an architectural problem being fixed. How often do you rename classes? This is not about "things you do occasionally" - there's exceptions to every rule - it's about your default working patterns and why you follow them.
1
@Stierguy1 Refactoring is: changing the implementation without impacting functionality - or to quote Fowler: "Improving the Design of Existing Code" Refactoring may impact performance (hopefully for the better), but usually, it's about code structure. If, in the context of software, "architecture" isn't analogous to "code structure" and "design", then I guess I really don't know anything about the meaning of words in the English language... While I'm all for shitposting and trolling for shits 'n' giggles (this I what "social" media is for...), I don't think it's fair to Dave to drag-down the quality of conversation on his channel. And before you continue your childish semantic game, what do you call it when you sit down with code and do NOTHING but a sequence of individual refactors (an extract method here, a collapse hierarchy there)? I would call that "Refactoring". If that results in a different architecture, well...
1
@dafyddrees2287 If it's changing lots of files, I wouldn't call that "trivial"... Maybe if you have a good IDE... But even then, if you've got a class that EVERYTHING is touching, then that sounds like a smell to me... And if it IS just a "trivial" name change, then when people pull-before-push, their merge will be trivial, so there is no need to worry about this scenario. Unless we have wildly differing definitions of the word "trivial"?
1
@dafyddrees2287 So, you're against GitFlow then? So, what are we arguing about?
1
@dafyddrees2287 🤣 I read about GitFlow in 2011 and I rejected it immediately as being contrived. I'd already seen many truly degenerate uses of VCS, so had taken an interest... I was already looking at things in a more abstract way; GitFlow is JUST a (yet another, degenerate) branching strategy - one you could implement in any VCS... and with that frame in mind, it's BAD, because a good strategy is independent of the tooling (they are all, fundamentally, the same...) and this would be bad no matter what VCS you used... I don't know how the confusion happened - will need to revisit this on my PC to do the analysis (but probably my fault 🤦🏻‍♂️)... There's a reason I HATE computers and prefer face-to-face interaction. Yes, it is ironic, given the business I'm in, but I'm still a pen-and-paper kinda guy...
1
@dafyddrees2287 🤣 Yep. Sounds right - no doubt you've been in those meetings, where you talk about the minutiae of VCS and branching and merging strategies??? But hey, we can't have those filthy programmer types working their "own" way that's highly efficient - they'll make us look bad!
1
Interesting. What you call "contextless bias", I consider "common sense". I dismissed Gitflow as soon as I saw it because I thought about it for about 30 minutes and saw how unnecessarily complex it was and how it just compensates for issues elsewhere in the development process.
1
If you think refactoring is slower than starting from scratch, I would point you to Perl 6... The philosophical leap here is understanding this choice: 1. Make sure every change works before moving on to the next. 2. Make a whole host of changes, then spend time working out why it's broken. CICD + TDD + refactoring is about choosing option 1. If you are maintaining the external behaviour, then you want to keep running against your existing test suites (or probably improving them as you go). If a change meets all the criteria, then why shouldn't you merge it back at the earliest opportunity? As to what process... Rewriting a whole module is rare, so treat it as an exception; just use branches as necessary with whatever quality gates your team feels is appropriate.
1
This, so much, this!
1