Ask HN: Why should my company use source control?

Reading the post title, I think my brain hit a segfault.

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.

Just get another job. Life is short and ain't nobody got time for this in 2020.

Yes, if you're in the position to find a job elsewhere, do it. This is an uphill battle that you don't need to fight. And there's no guarantee that you would win -- reason is of no use here. The most perfectly-constructed rebuttal will not be effective.

lol I laughed pretty hard but it is actually a good advice.

Otherwise I guess you can just use git in the NFS by doing git init and local git workflows... I can't do anything without git, even throw away code I start with git init.

Daily backups help nothing if you accidentally delete a file you wrote today. It's far too slow.

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.

First let me say HAAAHAHAHAHAHAHA

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.

Yikes. The snarky answer: find a better place to work.

I mean... people have been using version control for decades. It's not controversial.

While people have been using version control for decades it only became the norm for all projects since github became popular. 2010-13ish I would regularly meet senior/mid-level engineers that weren't familiar with Git. In companies that are not tech-first, it can be a battle to get developer tooling in place since its not a feature. Anecdotally, I worked at one place where the deploys were manual FTP file by file for a team of 12-15ish engineers. Automating deployments basically gave us back 1-2 engineers.

People have been using version control since I started coding professionally in the 90ies. Granted, it was much crappier (cvs and then subversion), but it still was much better than nothing at all.

I have worked at places where they just create a new folder and copy everything over. Backups do the rest. Occasionally they would ask for a restore and do a diff.

backup aren't usually reliable (and if they're not tested, they are absolutely not "reliable", you just don't know...), and that's a horrible way to get back old artifacts (it surely is excruciatingly painful compared to just using source control). I think anybody sane would just refuse to work at a company with such practices..

Well tbh this is a really great place to work at and I really enjoy it. I just want to make some progress on the tech tools front. There's a lot of other really good things going on at this org, so I don't think this will be a hill I'm willing to die on.

Something like this contains a lot of data:

https://www.atlassian.com/git/tutorials/what-is-version-cont...

I found it by googling 'advantages of version control'.

Instead of preaching source control, why not try framing the problem you perceive as risks that others can empathize with. If you can't, then perhaps it's not truely needed in that workplace.

Where are you coming from here? You're all over this thread hating on DVCS. Did version control kill your dad or something?

Why wouldn't you use version control?

yes why would one not use version control??, sounds like dogma to me (a bit little being anti-vaccine IMHO..).

Yeah pick your battles. Nothing really stops you from using git locally.

That's not a reason to use source control.

Imagine if instead of having to go ask the author why they made a certain change to the code, or look it up in documentation, every developer on the team already knows the reason behind every change made to the system, and this is true going forward even if the entire team is replaced.

That's a good point, me being new, I have already encountered a few projects where no one is really sure of why things are the way they are, but they work. I'll add this to the list.

Yep. To be fair, you really need to combine it with a good ticketing system to get that effect.

GIT does not make good commit comments. That's a practice that can happen without git.

The author's co-workers are objecting to using any version control at all. Here I am thinking, they must be database admins ;).

How do you make commit messages without any form of source control?

I would push on the version history, having a history lets you understand decisions and codepaths that lead to it not working correctly. This is invaluable, and if anything breaks majorly: you can roll back.

Yikes. I have had the misfortune of working in places where explaining the benefits of basic technologies lands on deaf ears. This happens a lot with regard to infosec (requiring 2FA, enforcing password manager use).

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.

You didn't offer a single compelling reason to use source control.

> Git allows people to easily collaborate on the same project

> 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.

Their last rebuttal is the problem. You could easily counter the others.

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.

Note that even if the company doesn't use version control, you probably can do so yourself (e.g., with a personal git repo) and get a lot of personal benefits. I've done this at a few shitty jobs.

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.)

What do your colleagues think? Or is every engineer in this big company also incompetent in addition to your management?

Actually management has been supportive about using newer technologies. We have a BitBucket server and it's updated regularly.

The general consensus from colleagues is that it's complex and is overkill for the type of development this department does. Many of the benefits I cite are already being met by other systems, so they don't see why they should bother switching to it.

If there was flooding and all the hard drives failed would you lose all the code? I've heard multiple times about game studios suffering a flooding and losing lots of code.

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.

Offsite backups should be in place for this scenario. It's also extremely rare, and any place not aware of this threat is probably failing in other areas.

...I honestly kind of agree with your department regarding points 1 and 2. If programmers never collaborate, and they have a backup system in place, then you don't need git for those things.

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.

I disagree in that it sounds like the OP's organization is staffing to the limitations of their technology. It reminds me of working in subversion where people would never collaborate for fear of commit collisions. This super bad from a knowledge perspective in that people don't cross train and instead become reclusive experts that they use to justify their existence and continued value.

For me, personally, the biggest win of git is ease of branching allowing for rapid and easily disposable experimentation in the source code.

This is a ridiculous question. If your current state doesn't work, then of course you want to go back to the last state available that works. Git gives you more control over this.

Right so (I think this is silly but this is how colleauges have been doing it for years) if a change to a production system is required, first people back up whatever artifacts are being changed to a folder on their computer or a network share. Think like stored procedures, report definitions, SSIS jobs, whatever the thing is. That all goes in a BACKUP folder, then you make your change, test it, then put it in prod. Then you hang on to that backup folder for 1 day to a month, depending on how often you clean house.

I think this is silly, of course. But the reality is this org doesn't have very many changes to production that go wrong, so maintaining a version history seems like added overhead to every change.

It's not even a lot of overhead though. They just make a feature branch, have that PR'd back into the master on github. That's it. Like 3 mins of work every medium feature.

If you have a breaking change in a new version of the code with lots of changes, or don't discover the break until several revisions later, git can help find the responsible code with git bisect.

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.

Tell them that you overwrote several hundred lines of code by mistake and now there is no way to get to the previous version. Do they have a backup for that previous instance ? If not, they have the answer.

If there is a piece of code that is uncovered by a backup, it's likely pretty new. For git to help you, you'd need to have committed that code at least once.

Yes, of course. But it's normal to commit many times per day, it takes hardly any time.

If you are otherwise happy with the job I'd say just let it go. You don't need to fight anyone or convince them.

> we only care about the current state and what it's not doing correctly

That's just too ignorant for words.

You're trying to teach bush people to boil water to kill germs.

what about code review? And if the answer is that everyone at the company is a rock star and doesn't ever need code review, then I'll be at a loss of words.

Actually this is a great point and something we want to improve on. Code review / pull requests would be a great talking point. I'll be sure to bring it up.

Every single line of code at my company is subject to a peer reviewed pull request and isn't accepted unless at least 3 people approve it.

That seems wrong, but on the totally opposite end of the spectrum. 3 people seems like huge overkill.

You can use git locally to get some of the benefits for yourself. No one even has to know. Distributed git FTW.

https://git-scm.com/docs/git-bisect

y, it's tough changing 'the way we've always done it'

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.

Which industry is this? Make a security / compliance case that mid-management cannot overlook.

Education.

That's what I was hoping to build here - a list of reasons why git is a better tool we should take advantage of. However, the business reason for many of git's benefits are already being met. For example, all source code must be backed up. That's already being done, just not through git.

Are there other security / compliance requirements that I should consider?

Why make it a security case, if it's not. If the IP is protected and available without GIt, why make stuff up.

How do you safely rollback changes?

Make a copy of system artifacts and store it in a folder called backup on a network share. If things do go wrong just copy the backup folder artifacts to production. May need to also write some data cleanup scripts if data was altered or columns added and so forth.

Is there a possibility you just like GIT because you have skills in it? Totally ok to be that way, you're probably productive with it, but are you sure there won't be a non trivial learning curve for others?

to be fair, if you don't know any version control, and aren't willing to learn it (in 2020 of all things!) then why the ever-living christ should anyone put up with that?

branches. code review. obvi you can do both without SCM but boy does it help

Here's an (extremely) short but useful explanation of 'why': https://docs.microsoft.com/en-us/azure/devops/learn/git/what...

TL;DR: source control is about so much more than 'backing up'.