What are the arguments against version control here (if any)?
Honestly the project sounds quite interesting, but I can imagine the circumstances make it painful.
Honestly the project sounds quite interesting, but I can imagine the circumstances make it painful.
* I don't understand it
* You're overcomplicating things
* We're not using any of that free shit here
* It doesn't say Microsoft or IBM
* The last guy we hired that tried to use it was smarter than I was so anyone else who tries is a threat to my leadership. (because everyone knows you can only manage people who have a strict subset of your own knowledge. If one of your peons dared learn something before you, that would be the end of your reign.)
the list goes on...
GitHub does, now, though I really hope that isn’t necessary for a company to adopt version control.
* It didn't exist at the time, but there was an on-prem that MS offered a few years back. It was forced on another department with no version control experience. It lasted about two weeks.
Git follows in spirit the model of BitKeeper, a software that already worked exceptionally well for Linus and other kernel devs. So Git had both a known good design from the very beginning and a decently sized installed user base (kernel devs) with an important project (the kernel).
IMO there's nothing wrong with the cloning of software. You make it sound bad, can you give reasons?
What else are you gonna use? SVN? shudder
I have no issue with a friendly wrapper in general, but after starting with the basic interface, I don't trust a wrapper to be logical, complete, and well thought out, given the foundation.
In the end it really boils down to a few commands that you use often, checkout/push/pull/commit/clone/branch/diff/status etc. It can definitely get confusing at times when you get merge conflicts and want to start playing with rebasing and stuff like that.
I've used it with teams with no experience with Git whatsoever and they're usually fluent at the basics within a week or so.
If you get stuck the command you need is usually a 2 minute Google away.
There's also this which is fantastically named! https://ohshitgit.com
You've never looked at a piece of code that you wanted to see the history of?
You've never needed to revert a single change a few hours/days/weeks later?
You've never needed to track down the person who wrote a piece of code in order to ask them for clarification?
You've never needed to see the original change reason for a line of code that is doing some weird, specific thing that seems out of place?
You've never needed to have two people edit the same file at the same time?
The question was "Let's submit pull requests as a clean job not as a homework draft. Why don't we allow push force on work branches so that we can squash fixup commits after review?"
Blows my mind that those are senior developers that are otherwise seemingly competent at what they do. There is some pinch of job security there though.
The thing is that in a lot of scenarios people need to do huge chunks of work in feature branches. Sometimes a 3000 line "refactor the world" squashed commit is really unhelpful. The best policy is always well thought of weighted case-by-case decisions.
However, on projects with a lot of hands on the keyboard such policy is unrealistic and someone will do the opposite of what they should and wont ask or discuss. People, especially in our business, hide incompetence behind aloofness and silence.
So in that case, with a lot of people that are hard to manage, stiff policy is the best choice and there probably are reasons why people want to preserve history, no matter how hairy it looks, at least it's there and you can find stuff in it.
If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees.
If your source code contains personal information, usernames, passwords, etc that should not be exposed to the public, you need to address that immediately regardless of any irrational stances on version control.
You need a better process. Developers aren't lawyers. Of course they should be aware of HIPAA requirements, but better is to ensure they simply don't have access to sensitive production data except in very controlled circumstances, while making safe anonymised test data available for anything they need test data for.
I honestly enjoy the work when I know what's going on. We have a lot of unique problems to solve, and I have gotten positive changes made, as well as some really good weeks where I pounded out some good code, but other times it's slow, sad, and frustrating.
I echo your ??. Sure you don't need a central repository to use git. What does that have to do with suggesting some git hosts that aren't cloud based?
I'm very comfortable with git at the command line, but I still think it's valuable to have a web interface. For instance, with a web GUI I'm able to share a link to a specific line or range in a file in a specific commit.
Typically if I need to do that I'm asking a question or requesting a change, and in that case I want there to be as few barriers as possible to increase the chances that the other person cooperates. Asking someone to clone/pull the repo, checkout a hash, and then view a line in a file is a much higher barrier than asking them to click a link.
There's a skill to learn in keeping engineering concerns to yourself. It's unsurprising when management or executives are faced with decisions in unfamiliar topics they err on the side of Nay. Your mistake is involving them at all.
Using git locally is a tool just like your code editor. There's no need to ask your boss about that.
Since you're the only developer it's mainly to make it easy to revert any mistakes and to have confidence in deleting useless stuff (that you can recover later).
No good ones of course, but there is one that I think is superficially very compelling:
It keeps a permanent record of everything that has ever been part of the codebase. If HIPAA required medical and patient data to not be stored anywhere except under highly controlled circumstances, the CEO might be afraid that data might end up in version control.
And that's not an entirely unreasonable fear; developers writing a quick PoC could include data in the project because it's quicker than setting up the infrastructure required. And of course they'll later fix it, but the version control system will still keep a record of it.
Of course there are tons of bad practices about this, but here's the thing: bad practices do happen, even if it's just as a temporary measure, and version control will create a permanent record for that.
Of course the right way to do this is to ensure that the developers only have access to anonymised test data and not to real sensitive production data; and to ensure that production data is always and only stored under the proper, secure circumstances required.
It's still a red flag, but the reasons might be more subtle and complex than simply "I don't understand it".