Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don’t let code become stale.
Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don’t let code become stale.
You lost me at “pair programming”. Having tests for what you can test is fine. But there’s code that simply can’t be tested, or at least not easily at which point you are just wasting time. Open source mantra is always great in my opinion… release early, release often. In addition to that have a test version of your software before you push it to production if there’s sensitive data. That’s usually good enough to catch issues.
And he’s right, reviewing changes before merge just takes time and resources away from project while the master branch keeps moving. Merge, if there are issues, whoever submitted the change is obliged to fix it. You can always checkout earlier version.
I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there’s a conflict but the automerge keeps drift to a minimum so it’s less common and fixed sooner.
better than merging poorly tested/reviewed code.
and yeah, a small team of superstars doesn’t need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.
it also leads to plenty of good conversations about the best way to implement, so overall it’s a win.
Well, Git was designed to branch out, not be a single repo with bunch of users. So one team can have a local repo, that in turn gets merged into big one, etc. Structure matters as you say. Small experienced teams move fast. Big teams require a lot of management and supervision. I still think it’s better to split people up into small teams and give individual tasks, or let them pick tasks that need to be done.