3 ms·

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 th

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.

lukeramsden 4y ago
Works absolutely fine with git, you just have to take the time to keep the pre-commit checks reasonably quick
- flohofwoe 4y ago
  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).
  - ilyt 4y ago
    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
fuzzy2 4y ago
> 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.
- usrusr 4y ago
  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.
- flohofwoe 4y ago
  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)
  - pyrale 4y ago
    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.
ilyt 4y ago
> 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

lukeramsden 4y ago

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

flohofwoe 4y ago
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).
- ilyt 4y ago
  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

fuzzy2 4y ago

> 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.

usrusr 4y ago
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.
flohofwoe 4y ago
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)
- pyrale 4y ago
  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.

ilyt 4y ago

> 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