4 ms·
> 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 importa
by fuzzy2 3y 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 3y agoA 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 3y agoThe 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 3y agoMost 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.