[maccard]

Using distributed version control isn't applicable to most people working in games.

9) is also debatable - requiring someone to clone the entire application to make an infra change to a testing environment.

Adding tickets to commit messages isn't necessarily a requirement - some work (at least in my area) is prototypey and maybe ill defined (the task might be to define it).

Being able to deploy from your own machine is a double edged sword; the situation you need this is an absolute last resort. Enabling deployments from dev machines means credentials to environments, write access to infra, and likely skirting around normal processes.

[KronisLV]

> Using distributed version control isn't applicable to most people working in games.

Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Unity also seems to be pushing their Plastic SCM as well for this more specialized use case: https://www.plasticscm.com/

Either way, not using version control for any collaborative project is just asking for issues.

Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

[maccard]

> Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Yes, and I never said you shouldn't use version control , simply that distributed version control isn't necessarily applicable (which is what the claim is).

> Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Let's be honest, LFS is duct tape on a pig. It doesn't support SSH, for one. Mirroring a repository is mired with landmines, and probably most importantly it breaks the decentralised model of git by centralising the storage of your binary data.

> Either way, not using version control for any collaborative project is just asking for issues.

Which is not what I said, at all. The article says _distributed_ version control.

> Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

By distributed version control you mean git here, right? The advantage of git isn't it's technical merit, or the advantages of DVCS (particularly if you're using something like LFS which turns it into a centralized VCS). The advantage of git is that it's well supported in many tools (ci, merge bits, code review, deployment, package managers). Frankly, my experience is the complexity brought on by git (which is quite a few years using it along side perforce and more recently plastic) often outweighs the benefits over something like perforce, particularly on large repos.