I'm a programmer at a big company. Prior to working here, I have worked at several other organizations who all used Git as a version control system. As a result, I am very well versed in how to use git.
However, my department does not use version control at all. They simply do not see a need for it. So far, most of my reasons for using source control have been discarded due to another tool already doing that thing. For example:
* Git is a backup of your source code. If your code is on the server, and you lose your laptop, you're still relatively OK.
* Rebuttal: We store code on a network share, which is backed up automatically every night.
* Git allows people to easily collaborate on the same project (branches, pull requests, merges).
* Rebuttal: We rarely have multiple people working on the same system at the same time - the benefits will be negligible, and only add complexity to our daily work (this is true, work here is very silo'd).
* Git allows you to store a version history so you can see what changed and why.
* Rebuttal: We don't care for the past: we only care about the current state and what it's not doing correctly (or needs to do / enhancement).
So, HN, my question to you is: what other benefits of Git / source control exist that I can bring to management to hopefully swing our team into using it daily?
I sometimes want to undo an hour of work. Git to the rescue.
I sometimes want to compare code now to code then. Git the the rescue.
Sometimes, I have to undo days of work. Git to the rescue.
Sometimes a really good git commit will help me understand why something changed (though, I contend this should be documented in the code with comments). Links to tickets, other files that were changed at the same time, etc. Git to the rescue.
I _want_ code reviews. It is how we learn from each other and get better. Git to the rescue.
I run automated tests against my code to make sure it works the way I want. Multiple layers. Especially at the black box layer (ie, does it do what the customer wants). Sometimes my new code breaks tests and I want to easily switch between the known stable version and my broken version as I fix my version. Git to the rescue.
Sometimes I want to share my code to help a colleague learn. Online source code viewer to the rescue! (cough, Github, cough). To leverage Github? Git to the rescue.
Being able to review code by a coworker before it is merged into master is also a big one, as well as having different versions around for currently in use, currently being tested, currently being developed and so on.
But they sound like they have already made up their mind, and you will build negative work experience in your time there...
Anyway you can still use Git locally I guess.
Now that I have that out of the way...
don't sell them on version control, they obviously don't care. Sell them on oversite in project management tools that are coupled with the code versioning system. Then bate n' switch them.
I mean... people have been using version control for decades. It's not controversial.
Quite honestly just do your best to move the company forward. There's really very little reason to not use best practice approaches, especially when doing so costs nothing other trekking the learning curve.
If you get too much resistance, find a better place to work.
If you are a dev, you don't want to be working anywhere that is failing to follow the most basic best practices.
> Rebuttal: We rarely have multiple people working on the same system at the same time - the benefits will be negligible, and only add complexity to our daily work (this is true, work here is very silo'd).
Working for long stretches in this kind of culture is likely to stunt your personal growth. You can learn more in 6 months of direct collaboration with someone who really cares about development, than in 5 years at a silo'd place with little to no collaboration.
First rebuttal:
> We store code on a network share, which is backed up automatically every night.
Git (and other version control systems) permit more frequent backups independent of policies established by the sysadmins.
Second rebuttal:
> We rarely have multiple people working on the same system at the same time - the benefits will be negligible, and only add complexity to our daily work (this is true, work here is very silo'd).
If most things are only touched by one person, then git (and most other version control systems) add negligible complexity. While not advisable, you could even have them work off of master (as they do now anyways). [This lets git be a gateway to process improvement. Once they see the fine-grained snapshots and realize they could have people work on the same code at the same time, they may start using branches and other capabilities.]
That last one, though, indicates they don't actually care about anything. The past is not gone. Having these snapshots lets you do a lot of useful things like git bisect. Or the ability to easily rollback to a known good state. If they really don't care about that, I'd run, not walk, to the nearest exit.
Believe it or not, it's better for you that there is no version control than that they force a bad one. (Looking at you, Perforce.)
Version control has lots of uses, it helps you branch out and test new ideas, it saves your code from local doomsday scenarios at the office. Helps you to ask the correct developer what the code is supposed to do due to version commit history.
You can always keep your own local git repo. A coworker had a git repo inside an SVN repo, just add each version controls contents to a git / svn ignore file.
But point 3 is a super big one, so I'd focus on that. Is there really know time when your company took something out that they realized they wanted later? There's never been a regression they had to roll back? Really?
If not, you might tell them that it's helpful to you as a programmer to be able to refer to how something was done previously.
The idea is to manage and track change to your code base so that you can answer questions about the code base efficiently when there are problems.
That's just too ignorant for words.
You're trying to teach bush people to boil water to kill germs.
I would just use git/github locally for what you work on, then you can enjoy the benefits.
Perhaps at some point they will need to see what something looked like 6 months ago and you can WOW them with the magic of GIT.
Good luck, it's tough trying to change culture.
TL;DR: source control is about so much more than 'backing up'.