With that setup, your code is probably going to survive on employee-controlled disks past the employee's end date. Even if they delete it, it's probably still

With that setup, your code is probably going to survive on employee-controlled disks past the employee's end date. Even if they delete it, it's probably still on disk, after all. Companies that care about whether or not their code gets copied implement quite a bit of security beyond "use your own computer to clone a git repo". They will issue laptops and workstations that are locked down and remotely controlled. They will segregate codebases based on whether or not someone needs that specific codebase. And, they won't let you clone the full repo if you only need to work on one part. I worked at Google for many years and I thought they had a very reasonable approach; you couldn't access any code-related services without a special laptop, they used build systems that run on servers they control instead of developer workstations (probably for better caching rather than security), and they didn't give access to the most important stuff to just anyone. Obviously, building that infrastructure probably cost more than your small company has received in funding (or even plans to ever make!), so it's probably impractical to do it yourself. Plenty of people willing to charge you a lot of money for a version that's 1/10th as good, though, and maybe something is better than nothing. I would personally worry a lot more about what happens when someone's workstation gets infected with malware, and the malware starts checking in code. Someone having a copy of your code doesn't sound like much of a disaster. Maybe annoying. Someone having write access to your repository does sound like a disaster, however. That's how your database gets leaked, that's how your servers start mining bitcoins, and that's how your website starts serving malware. Given finite resources, I'd focus in code going in rather than code going out.