Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Up to about 10 years ago I used to work on projects where up to 100 people (of those about 20 coders, the rest artists and designers) committed directly into the main branch without a formal review process, and it was ok (this was with SVN though).

Code review happened informally "after the fact", usually as the first thing in the morning when updating (each person simply looked through the changes of other people in the part of the project they felt responsible for - usually those changes were no surprises because people talked to each other before doing this).

"Post-commit" breakage was surprisingly rare, and when it happened it was quickly fixed. One just was a bit more careful checking for errors before committing changes.

I cannot imagine how this scenario could work with git though.

View on HN

> I cannot imagine how this scenario could work with git though.

I cannot image how this scenario could not work with Git†. Maybe I’m missing something important about Subversion, but it’s also just plain old version control. Nothing fancy like Darcs.

†: Granted, there is a (theoretical) point where the frequency of pushes becomes so high you can no longer reasonably work on a single branch.

A possible reason is that it won't happen in git, simply because separate branches aren't sufficiently painful to motivate sharing that single hot mess HEAD. I used to work in a team where it felt like I was the only person who ever thought about these things and it was quite impressive how the switch from SVN to git completely flipped the path of (supposedly) least resistance: from separate branches only as a last ditch option for the most desperate situations to happy unbounded parallelism right until the (supposed) delivery day.

The big difference between SVN and Git is that SVN is centralized (a single linear history is enforced at all times for everyone) and Git is distributed (each user has its own local history).

Both models have advantages and disadvantages, but for many people working on the same branch the centralized model is arguably better.

(in the end, both Github and Gitlab workflows mainly try to put more 'centralization' back into git)

Most corporate git workflows using git are also centralized : the team has one upstream, and people's local repos function as mere clients to check out the upstream. Few teams pull from each other's repos.

If you don't branch and directly push what you commit, there's little difference between SVN and Git.

Works absolutely fine with git, you just have to take the time to keep the pre-commit checks reasonably quick

IMHO what makes it harder in git (for many people committing into the same branch) is that each team member has its own local history which needs to be synchronised via push and fetch (which quickly gets out of control for 'non-technical' team members). This separate step doesn't exist in centralized version control systems like SVN where everybody is always on the same timeline.

Working exclusively on branches and then merging into a common main branch pretty much fixes this problem though (that's why the PR workflow make a lot more sense in git than svn).

You can make it do automatic rebase on pull to make it look more like SVN single history.

We do that on our CI repo because of many tiny changes of unrelated parts that otherwise just made almost every second commit into a merge

> I cannot imagine how this scenario could work with git though.

exactly the same as with SVN ? The one feature I could see it lacking is ability to lock file in SVN but otherwise "single master repo" work on SVN and Git is very similar

Reply on news.ycombinator.com