You don't. Having isolated code bases for each developer and a well-defined merge procedure is a feature, not a bug.

I've seen teams develop on a single target system, all of them bashing on the same source code base at once. It sort of works with a well-tuned team, that communicates well, and is capable of dealing with the resulting inconveniences, up to maybe 3 or 4 developers. Probably helps to have dynamic scripting languages in use by most of the devs so you aren't trying to time your compiles with each other's actions. And they still stepped on each other more than I would have been able to tolerate. There's no way this scales.

For non-code documents, by all means share. English prose doesn't crash if you start editing page 5 while someone else has an incomplete sentence fragment they're in the process of changing on page 2. But trying to edit code that way doesn't scale for squat.

From this point of view, whether it's "files" or "a database" or whatever that's being developed on isn't relevant. The point is that I actively do not want somebody else's half done work randomly getting integrated with what I'm working on right now.

How do you test something is working if one person is making changes?

You stop then test.

You're going to ask everyone else to stop working while you test something? Even if they agree, what if they continue working in between your changes? What if they are halfway through something and the code won't even compile until they're done?

I'm sure you have good ideas about better workflows here but I don't think they're as obvious to other people as you maybe assume?

Not sure if you've ever used git, but developers usually create a branch before editing.

So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test.

> a bunch of you discuss and edit in real time.

So now you have to get everyone into the same headspace at the same time and schedule coding sessions across timezones?

What if two people independently feel like doing some quick incompatible changes late at night? Do they have to message everyone on the team to see if it’s OK? Or do they make a branch of the branch of the branch to test it by themselves? How is that more convenient? And in that world, how can you do those tests privately, without everyone on the team (plus the service you’re using) being able to see them? And what happens when you don’t have an internet connection (or your service is down) but you want to continue working?

I agree with the parent comment, there are too many unanswered questions in your proposed scenario.

The whole blog post in general feels incongruent, and it’s not surprising to me you’re getting conflicting feedback. You’re conflating different scenarios and proposing broad vague ideas which are not only impractical for a multitude of scenarios, they remove user agency and give more power to corporations, which is exactly the opposite of what we should be doing.

Once you have branches, you have merges, so you're back to a version of git that's somehow less convenient.

How do you personally do that branching without git? What tool(s) do you use?

> So you make a branch, a bunch of you discuss and edit in real time. Once everyone is ready, you stop and test

What if you want to test your work out, and don't want to wait until everybody else has finished with their work and stopped working to test? What if you don't want to try to coordinate 100 different instances of "everybody stop working (but also make sure the build isn't broken), I want to run tests" per day?

I think what your parent comment is getting at is “how can you reliably test your changes if someone else is changing something else somewhere which may interfere with what you’re editing”.

Your “one person” rebuttal doesn’t work, because one person is not sabotaging themselves in other files of the same project.