Git Flow is Bad | Prime Reacts

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[NathanHedglin]

The real answer is to not use GIT. Everyone works on the same computer at the same time.

[redlancer]

My favorte part of Mr. Prime Agen is that he's totally cool with "I was wrong" or "I misunderstood this before." Everyone needs to be okay with being wrong sometimes and it's so nice to see someone like Prime being so casual about learning new things and getting better.

[MajesticNubbin]

Continuous Integration is *NOT* the automation pipeline you build or the tests you run, or the platform on which those tests get run. Despite the confusion caused by platforms branding themselves as "CI" and the regular misuse of the acronym.
Continuous Integration is simply: "everyone merges their changes into the main line very frequently, ideally multiple times a day in small chunks". That's it.
The pipeline of tests, and the use of feature flags to disable incomplete work and all of these other things are there to facilitate developers integrating their code "continuously".

Continuous Delivery/Deployment are then just additional layers that sit on top, these layers are again facilitated by automated pipelines, checks, tests, etc.

[xesf]

You don't need to keep your release branches. As long as they are tagged with a version, you can recover that branch at any time, create a new one, hotfix it, versioning, release and delete the branch.
Branching Strategies shouldn't be imposed like Dave is suggestion, but instead the team that is going to manage the repository and releases should find what fits their needs.

[andrewthompson]

I think I can address a bit of confusion - When Dave talks about the minimum integration frequency of being 1 day, and you talk about being a rebaser and "Why wait a day to update?" - As I understand it, he means integrating all diverging branches, and not just the one you are on. You can update your branch as often as master is updated, but nobody else who is diverging is going to get your changes until you merge.

[edd]

I think it would be super interesting if you can have Dave Farley on stream and discuss topics like CI/CD or TDD

[daniel-wood]

This guy talking about CI reminds me of the business people talking about "lean manufacturing"--it sounds very neat and pretty in theory, but it falls apart when subject to the constraints of reality. Ultimately, optimizing your production processes for philosophical purity does not create the best product, with the fewest hours invested, at the lowest cost.

[stephenreaves]

Finally this guy is catching some heat. All of his videos seem to be "This thing you're doing is wrong"

[BenRangel]

there's a disconnect between how an evangelist for CI/CD talk vs how an average devs talk of "we use a CI-server". So I kinda avoid using the term CI/CD outright when describing what what team does.

I just describe it in a simple way: "we don't push directly to master. we use feature branches and on each push, a server runs our test suite. We can't merge a PR to master unless it's ✅. Master should always be releaseable. we TRY to make small branches, and ship often. But we'll make exceptions"

[cheebadigga]

I agree with you. I think his definitions of "git", "(feature) branches", "continuous integration" and "testing" are vastly different from ours.

[ddanielsandberg]

Continuous delivery is a way of working (with a lot of automation) to ensure only good builds makes it to production. It is a falsification process where the "bet" is that the build is a release candidate that will pass the crucible and make it to production - but most builds won't. CD is the codification of the organization's processes and SDLC cycle so that every change is verified and has an audit trail instead of process theatre where everyone pretends the process is followed and done doesn't actually means done.
Continuous Deployment is the same as Continuous Delivery but the final human "approval gate" is automated. Continuous Delivery is not "every commit goes straight to production".

[lucianafruin]

You're missing some context here. David's idea of CI/CD is essentially based on the idea that your local copy of master is continuously updated so that you're never working on old code. Conversely, it means that your work is continously being pushed to master so that no one on your team is working on old code. You can do this how you want, but rebasing frequently is a good start.

[crhayes]

My interpretation of Dave’s central argument is to avoid all team members building large features/changes to completion in long-lived, isolated feature branches, then trying to merge back to main.

Even if everyone is rebasing frequently off main, all feature branches are diverging from each other which can cause hell when everyone wants to merge to main.

Feature branches are fine, but they should be short lived and merged to main quickly (ideally within a day). This means larger features/changes need to be broken up, merged to main, and shipped incrementally.

If the changes are not ready for users they need to be hidden somehow. This could be through feature flags or simply not including the “entry point” of the feature in the UI (Dave has a separate video on this).

Note: Dave argues taking it a step further by substituting code review with pair programming and pushing straight to main. I’ve never done this so I can’t comment, but I think a standard GitHub-style PR/review workflow aligned with what I mentioned above gets you 90% of the way there, particularly when coupled with good team communication and an emphasis on prompt code reviews.

[JLK]

This like saying "Electricians work best with the main breaker says on. They'll know the second they do something wrong".

[animanaut]

i think when talking about CI/CD you always have to consider the context: little library, application, oss, live service, devices, ... i assume his context was in the live service area. he also often mentions the DORA metrics and his co-author was a driving force for these. these were mostly focused on live services i think. in the end it has to evolve into whatever works best for your case so there cant ever be a one for all be all

[holonaut]

I am actually shocked that the word "trunk based development" was not mentioned a single time by any of the 2 devs with multiple years of experience, in this 30 minute video about trunk based development.

In summary:
- Branches are not supposed to live longer than a few days. They always branch off from, and merge directly into, master. As soon as they are merged, the branches are deleted.
- Use feature flags when working on larger features, so you can continually merge your changes, without giving customers access to an incomplete feature.

[calder-ty]

I've worked/do work on a project where people push directly to master. Since we all work on completely separate things for the most part, it _works_ but it is awful. My 2 cents (which is overvaluing it): I think developers are particularly prone to falling for a trap of getting things done perfectly/most efficiently as possible. It's a mindset where any setback, any inconvenience is a failure. I'm fine with a system where i might have to do an awkward merge conflict resolution every once in a while. Dealing with surprise is just a cost of doing business in life.

Fwiw, when i do work on projects (usually pretty small), I like to have a protected master branch and then just branch off that for features/bugfixes etc and merge them in via PR, with CI only running on PR's, and using local unit-tests in between. I'm sure it has a name, but i just call it using git.

[kkiller]

The entire concept of "continuous delivery" seems to be something like "discover footguns as quickly as possible by firing them as many times as possible in production systems".

[ttuurrttlle]

I feel so validated hearing your take on this video. I watched it once months ago and similarly thought it made no sense. And it makes no sense because of how he describes the branches/pushing/testing.

He mentions making changes to his fork of master, and then clones of master and doesn't really make clear which one he's talking about in the various references he makes to it. Like it seems like he's talking about pushing to master, but really means like a push from his local copy of the fork branch to his remote fork, then from the remote fork there's automated testing (or PR that triggers it) that has to run before allowing the PR to be merged.

But he doesn't mention PRs and he doesn't really describe the testing in his Ci Pipeline except when he mentions running the tests locally before pushing to his fork. Running the tests locally isn't bad per se, but that's not really part of the pipeline because how can you really enforce that when making a push to your fork or even master?

[dforj]

CI is about how your team works together to write software in order not to have mega-merges. It is orthogonal to your deployment strategy, which could be direct CD to prod, release of specific version after UAT, canary, etc... You can use tools (e.g. deploy by tag instead of branch) to use any deployment strategy you prefer and the proper implementation techniques (e.g. feature flag) while doing CI (=no mega-merge) in your team.