Comments by "DR" (@dafyddrees2287) on "Git Flow Is A Bad Idea" video.

In "lean" terms all the superfluous git flow branches are inventory we're holding onto. (Feature branches are pure "muda".)
24
I worked with 30 devs across Singapore, the UK, and the Western US - all sharing the same big codebase. We managed to work together closely and in all of four years we hardly ever needed to use a branch. We all shared the same codebase - with common ownership (i.e. anybody can change anything.) No need to "fear" anything - you just have to learn the XP way of working in a co-ordinated fashion. Branches are no substitute for working closely with other people. Now I know lots of people fear doing that and don't want to face the possibility of it - but it does actually work. My "nightmare" is not being able to get rapid feedback about things on separate branches working together - that totally kills my ability to refactor and simplify things. The code becomes very, very hard to change- and very quickly. Working with my 30 colleagues on a trunk is a lot easier because catching up quickly with changes - and learning to make small commits makes it much easier to refactor complexity away.
20
When I first saw the gitflow diagram I felt sick at the sight of all those arrows. Every one is a potential merge hell. It's great for the "muggles" (non-developers) that worry about what's in a release but never have to use git directly to resolve a merge.
5
Thankyou so much. It's really useful to have a place I can refer people that mandate gitflow. (I had to revise this comment several times to remove swearing.)
4
@zauxst You obviously have never used “MercilessRefactoring” - you must just leave inconsistencies and design burps build up everywhere… or spend almost all your time merging. You have never tried to do XP and CI properly. Lol…. (Why are devs so soften arrogant pricks?)
4
@Keilnoth Feature flags are a bit of a worst case scenario because we don’t want a combinatorial explosion of switches undermining the usefulness of tests on a CI server. The trick is to build things in the order you want to release them and release very often. We did branch for hotfixes - at that point you are maintaining two different versions of the app anyway. We almost never needed a hot fix though - it happened very rarely, like once a year.
3
@edwardcullen1739 "If you have large amounts of merge conflicts, then you have an architectural problem." - Not necessarily. Example: You realise that a class name is not as clear as it should be so you rename the class. This affects all the code that explicitly mentions the old name. That can easily cause loads of merge conflicts with other people. That's nothing to do with architecture. Also on a large system that's long-lived enough sometimes you have to refactor important mechanisms - is that an "architectural problem" or just a realisation that the system needs to change to accomodate new functionality? Either way - "keeping up with change" is very important. Saying a merge is no big deal misses the point - there's a stream of refactorings and changes coming.
3
@edwardcullen1739 "How often do you rename classes?" That's not architectural change - it's a trivial change that could touch loads of text across a codebase. Besides - I don't feel it's reasonable to partiton changes into simple ones and "architectural" ones. In a team of 10+ people - somebody will probably rename something every day - and that's not a problem with Trunk-based dev. We set things up to be able to handle change easily. You set this whole question up with the preconception that we need to avoid changing things - and that if we do it's "bad". That's the opposite attitude of extreme programming. We keep the code as small and minimal as possible - and don't hold off making simplifying changes. Code needs to be in a state where it can be changed, continuously in tiny increments that are visible to everybody. The more afraid people are of change - and hence build up big change sets - the worse changes are going to be - so people end up living with huge piles of crap because they don't want to cause "architectural changes".
2
@Jheaff1 "Exactly. Is Dave suggesting we don’t do code reviews?" - not necessarily. Two options: 1) Pair/mob programming (i.e. continous review - which has lots of other advantages. and 2) Get your work reviewed one small commit at a time and get the other dev to review it before committing it back to master. (So, it's like pairing but asynchronous.)
2
@zauxst I meet loads of people that do devops and dev “by trade” that haven’t ever learned to do things the XP way (including CI.) It’s pretty rare and getting rarer. You’re the one with the attitude problem here mate with your supercillious use of “lol” after demonstrating clearly that you don’t understand why lots of merging would be a problem getting in the way of “MercilessRefactoring” (yes, it’s a thing - if you dropped the attitude long enough to learn about it you’d answer your own question.)
2
@SamirAbuLina yes there are loads of commits. What exactly is the problem you’re talking about?
1
@edwardcullen1739 "Refactoring large amounts of code to implement a new feature" No. That's not what I said. One, indivudual renaming on it's own is enough to cause loads of merges - either for you or everybody else.
1
@yaghiyahbrenner8902 how do you handle the stream of changes that arrive before you squash? How can you make lots of changes if you work in isolation from master? Don’t you either end up with a branch that’s hard to keep viable because you’re merging all the time?
1
@edwardcullen1739 " if you've got a class that EVERYTHING is touching, then that sounds like a smell to me" Not necessarily. Real example: We had a product that almost 30 people had been working on for about four years.... It sent binary messages to hardware devices. The assumption was you could send multiple messages to devices to set them up and we had built a product on the basis of that - hey it had been working in almost every country in the world with devices from most manufacturers (with all kinds of abstractions to allow for all the different quirks and bugs of different hardware and firmware combinations.) Then it turns out, the biggest manufacturer of the device we were sending the messages to made a mistake in their firmware - and we'd have to set them up with a "single shot" message and they now had thousands (millions?) of devices that had wrong firmware. You can't build software to be completely general - you have to build on the domain you're given... and then one day some new constraint nobody has had before that will force a change. It's not some "smell" - i.e. a design mistake or oversight. Our requirements became more general i.e. 1) continue supporting existing services and hardware in the field and 2) support the new hardware that only works by breaking an assumption that had been stable for four years.
1
@edwardcullen1739 "people pull-before-push, their merge will be trivial" I used to think that too. How do I get an isolated renaming into a gitflow repo? It won't allow me to make a trivial renaming in isolation. If I'm working on a story don't I have to package up all the changes on a feature branch into a giant change (that comes from squashing the changes on my feature branch.) If I follow the gitflow rules and my renaming is on the feature branch (because the rename occurs naturally as part of the feature) I get a great big change with loads of refactorings AND behavioural changes that no other developer will want to swallow when they review the PR. Now that is a nightware - trying to understand multiple refactorings AND behaviour changes all in one - i.e. gitflow actually making it hard to understand because all the changes have been concentrated together. I understand I could make a separate refactoring branch (if I knew in advance what I needed to refactor). I mean I could make an experimental throwaway branch and use it to work out what needs to be simplified to support the new behaviour and then create a series of "single refactoring only branches", and then make a "real" feature branch to work on top of that. The certified-professional-meeting attender class (i.e. non-engineers) won't like "single refactoring only" branches because forcing all devs to commit features as the merge of a single feature branch makes release management easier (at the expense of CI)... and of course refactoring and keeping the code simple isn't a problem for them so why would they care? I often see refactorings and how features could be really simple - and then remember that level of refactoring would never survive in a gitflow environment - so the other devs I work with never get to see how much simpler the codebase could be and I end up spending a lot of time being frustrated by working on code that's much more complicated than it needs to be and it can only get worse.
1
@edwardcullen1739 "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." - I had a moderately small number of small, easy merge conflicts until gitflow was imposed. After gitflow I had either 1) no serious refactoring or 2) refactoring on the feature branch, squashed into a super-commit that is hard to merge because it's multiple refactorings plus changed functionality. It would be easy to merge even a big rename if it's ONLY a rename in the merge. It's a disaster if it's multiple refactorings and functionality - as would be the rule for anybody brave enough to do that in a feature branch. Gitflow IS the problem here. The sticking plaster is usually not refactoring anything - I'd rather use trunk-based development which doesn't have this problem.
1
@edwardcullen1739 " So, you're against GitFlow then? So, what are we arguing about?" - Yes. I'm not sure how you got to that. I thought you were arguing for gitflow?
1
@edwardcullen1739 I've never seen anything destroy my ability to refactor and to make quick fixes as much as git flow did. It's not that there are 10x productivity developers - it's that things like gitflow takes normal developers and multiplies their productivity by 1/10. It's very, very frustrating - given that most devs today haven't got an XP background they probably don't realise what I'm trying to do or how much I've been snookered by gitflow.
1
@midoevil7 "sometimes the business team is just not sure yet if it should be released now" - So you could 1) use a feature toggle or 2) A-B test if (if that helps the decision)
1
@midoevil7 "sounds as if the team is only working on one feature if there is an "order" ? - Usually in my projects clients have more work than we ever have time to do and they have to decide what things come next. In XP there's a priority order for stories inside an iteration but more than one thing being worked on simultaneously. Commonsense and teamwork is used between people to ensure we don't step on each other's toes because it's better to avoid unnecessary problems than to have to fix them.
1
@midoevil7 "What if the feature is cancelled, how can the team quickly undo the feature from the codebase ?" You might have to roll back one or more commits. Rolling back one isolated change isn't usually a problem. How much effort it takes to cancel a feature depends on how much needs to go - are we pausing something maybe to take a different approach or "not now " or getting rid of it entirely? It depends on the business. Working in small increments and releasing often makes this less of a problem than with feature branches. Scrum in general has provision for cancelling sprints and time for backing things out of a product (or at least making sure they're not in the way.)
1
@midoevil7 It's certainly easier to throw away a branch you don't need. I'd question why anybody would build up something substantial that then needs to be thrown away?
1
@melmartinez7002 every project I’ve worked on was developing multiple features in parallel. One of them lasted four years and had devs in three sites in three different time zones and we had 30 people pairing on different features on trunk. Did you really think I was talking about only developing one feature at a time? No. Seriously feature branching is not the only way to dev “complex” projects….
1
@melmartinez7002 I said “feature toggles” are a worst case scenario not “feature branches”.
1
@melmartinez7002 Let’s not “straw man”, heaven forfend. You said “In many scenarios, multiple ‘feature’ efforts being developed in parallel are very much the norm”. Me too! Multiple features by many people, in parallel on trunk.
1
@melmartinez7002 "They can result in shipping unused code" - ah, my favourite refactoring: "remove spurious shit" ;-)
1
@Invatator No. "Local copy" is a clone of master. No unnecessary branches. We do not want to PR every tiny change and we don't want to manage a separate branch - because we want to integrate continuously not only when everything is finished and it is too late.
1
@Invatator " "tiny change" needs to have it's own ticket/change request, for traceability, audit," - Bullshit. You've never practiced extreme programming have you? If I did that I would spend 50% of my day shuffling jiras or index cards. Nobody would ever tolerate that. Audit? Funnily enough, my team did get audited by one of those ISO process audit guys - and he was perfectly happy with traceability with us all working on trunk.
1
@Invatator "With forking you don't need to "keep a separate branch" if they are short lived, purged at the time of the merge." - No. If other people in the project are also committing small changes and refactorings you will have to keep up with a stream of tiny changes from other people. Now you can add in a whole bunch of unnecessary process shuffling updates or work closely with other people on a single branch. I'm not saying you have to do trunk-based development - do what you like, but continuous integration means everybody working in synch on a common codebase, not pretending to work in isolation - even if only for a short while. CI just works better if we avoid unnecessary branching. This whole thing of copying how Torvalds works is so wasteful and damaging. Why does everybody have to pretend to be maintaining a huge, high-profile open-source, general purpose operating system - almost nobody needs to work like Torvalds. So much damage has come from the celebrity endorsement.
1
@Invatator "Give it a try, practically, brcause theory is riddled with logical falscies and whatnots..." Oh really? I don't have much time for theory but I have about 7 years of working with trunk-based development successfully in three different industries. Why don't you park your ego and consider that you don't know everything?
1
@Invatator " this is getting ridiculous, and childish." Yes, I agree. I don't understand your problem here. You say you want every tiny change to have it's own ticket/change request.... and then you tell me you've done "extreme programming" and that "is apparent that extreme programming concept is different amongst us". It's apparent to me that you don't know what you're talking about. You may well have loads of years of development - as most of the gitflow advocates do but so what? We're talking about why gitflow sucks and why CI with tiny incremental changes on one branch is a much better proposition for CI. From what you've said it's clear you've not actually done anything remotely like XP - but that's okay - branch all you want. That's all your problem - but that completely ignores what Dave was saying about CI working better with the whole team working incrementally on one branch.
1
@Keilnoth Normally we pair/mob with people in our timezone. Occasionally we'd pair with people in other timezones - but time lags with large distances over the internet tended to make that painful so we used to limit it. Most companies (at least until recently) used to keep subsystems within one geographical region even if they have to integrate things between regional teams.There's an argument that pairing/mobbing is more difficult done remotely and because of that there's more need for documentation and modelling. That may well be true. Distributed development certainly isn't free like a lot of non-developers seem to think. For one thing, turning on line numbering and referring to things explicitly helps (to prevent misunderstandings) and pausing frequently to check the other person understood what you did/said. That makes remote pairing/mobbing much slower - but I'd rather do that than just hope everything was understood and face a mess later when it isn't.
1
@andrealaforgia5066 "I would question the decision to create a team of people who cannot effectively work together." Sounds like that's generally true to me ;-) It's certainly easier to do distributed dev if the timezones align. People have this fantasy that because it's "agile" they can play fast and loose in all kinds of ways and still expect effective working software. Something always has to give. Remote dev may well require slower collaboration and more documentation - a shame so many people aren't prepared to face up to that. They're happy to eliminate pair programming but they're not so ready to reinforce what's lost with effective documentation and effective, meaningful work tickets in something like jira.
1
@Invatator "you're far off in your assumptions, and understanding on what I was saying" - You said : "tiny change" needs to have it's own ticket/change request, for traceability, audit, etc" No need for me to "assume" anything. That's just plain crazy right there. That makes no sense to people that have been doing XP. You said " it sounds/reads like your proposition is "you can't do CI with XP"" - I never said that - and I never suggested that.
1
@Invatator "if 2 dev work on same base code touching the same files each doing thier own changes, it means the base code breaks one of the SOLID principles, or the division of work, split of the tasks is not done correctly...you're bound to have clashes - inherently!!" - Yes - most days there will be conflicts and that’s not necessarily anything to do with breaking the SOLID recommendations: All you have to do to clash is rename a type. The trick is to make the changes tiny enough so it's easy to deal with. The fewer differences there are between the code on each dev machine the easier it will be. We want to flush changes through the system easily and keep syncing up regularly.
1
@Invatator “just because FANG use it…” We were using it before any of them and we wouldn’t have cared less. We adopted XP because we read the c2 wiki and saw a lot of practical wisdom in it.
1
@ContinuousDelivery When you see people attempting to do CI with gitflow and have zillions of branches being built - that's when you know CI has gone through what Alan Kay called "the great low pass filter of life" ;-)
1
@fluffysheap that analogy just doesn’t make sense.
1