When the boss asks why Git is good, can I justify using security as one of the reasons?
Under Git, it's easy to track changes. Maliciously altered files can be revealed with a simple 'git diff' on the command line.
Even if attackers were able to do their own commits and rewrite the commit history, they likely would not be able to push to origin. But even if they could, other remote instances of the git repo would still retain the original history and get errors when they try to push.
The security features of using Git might not be straightforward as they depend on what you're using it for, but here are some ideas.
Version Control - duh. But if you're using Git to track configuration files, Software Defined Networking, infrastructure provisioning code, or a deployed application, and suddenly things don't work. You can (theoretically) revert to a known good configuration, see what changes were made, and see who made the changes. This provides auditing and (a form of) disaster recovery. Furthermore, if it's used to manage puppet configs or Infrastructure as Code, it can serve as self-documentation. All of these can protect against downtime.
Hashing - Though SHA1 is considered much less secure now that an intentional collision has been demonstrated, it's still unreasonable to expect almost any malicious actors in a reasonable amount of time to be able to modify anything in your git repository that would stand against scrutiny.
Those are really the only benefits that come to mind, but using something for a version control of configuration files is a huge deal for enterprises. When you have many people capable of "fixing" configurations on your networks and servers, version control provides a very strong mitigation. Generally it would need to be paired with configuration management like Puppet or Salt.
Even if attackers were able to do their own commits and rewrite the commit history, they likely would not be able to push to origin. But even if they could, other remote instances of the git repo would still retain the original history and get errors when they try to push.
Whether malicious modifications to the Git history actually get detected depends a lot on the contributors' workflow. A developer who does a lot of careless rebasing might easily establish an unauthorized edit. Luckily, Git has a feature for GPG-signing commits which can mitigate the risk (if used consistently). This article is also a good read on repository integrity and rogue commits.
A different argument that might appeal to your boss is that they can trace back security-related bugs not only to an exact date but the individual contributor. This way they could easily identify developers that need additional security training. But honestly, even without security arguments there should be no debate about the advantages of proper source code management.
Tracking altered files with Git has been there for some time already: tools like etckeeper are used to track changes in server configuration. But don't expect miracles: Git is a version control tool, not a security tool, it will not warn you if an important file changes unexpectedly.
Frankly, if you can't convince your boss to use Git because of its version control features (as in, we have to use it to be sure we don't lose our files), I don't think that throwing security aspects in the mix will convince them.
