[denton-scratch]

I'm retired now. I spent most of the last 10 years of my career working for web-shops, mainly making Drupal-based websites using custom modules. This is the kind of work that the majority of developers do; it's not unusual, it's the norm.

[Edit] Just noticed that the commenters above that seem to agree that I'm unusual, are all different commenters. I'm puzzled that people think I'm unusual, even to the point of asking about the work I do/did. But the sub-conversation is about Github; I presume that most of these commenters is a Github user, who works in Githubby environments, and so is exposed to a lot of Github users.

I'm really not very unusual; I'm just an opinionated graybeard old-fart software geek, like a lot of us. We all have strong opinions about what software we're prepared to try to cooperate with.

I found git over-complicated, and Github quickly became like a cross between LinkedIn and a sort of Facebook for coders. I never trusted it at all.

[bbsz]

That's interesting for me.

I was born in 93. In 2000s all of my then web-deving with html/php was without even an awareness of something like version control. I was storing snippets of code in .txt files in case my change (often made directly on the FTP server) was to crash everything. Of course, this was just a hobbyist environment, I was a teen running some small personal communities. Then, I stopped programming for years and when returned around 5 years ago `git` was basically everywhere. Now, after working in "professional environment" with software development, I don't imagine running any project without some version control when more than 1 person is involved.

What were you using for version control, how did that work between programmers committing to the same new feature?

[denton-scratch]

> What were you using for version control

I started with CVS. I had been aware of sccs from an early Unix training course, so I knew how diffs worked, but I never used a VCS until I needed CVS. Later I switched to Subversion, which I think is pretty good, for my use-cases. Subversion flags a conflict if your commit against rev1.1 is submitted after another commit to the same file, but against rev1.2. You have to figure it out yourself, or grab rev1.2 and redo your changes. Git has lovely features for dealing with conflicts, much better that Subversion. But in practice, in a team of (say) three working on a feature, and communicating well, conflicts are rare, and easily resolved.

I should have been using revision control since the early days, of course; but I don't think many of us did - it required more storage, and floppy disks weren't cheap.

[Edit] Perhaps I should note that for a time, I had to work with Microsoft's Visual Sourcesafe, over Frame Delay, to a repository across the Atlantic. Those were bad times.

[captaincaveman]

I agree with Git being overcomplicated, and the commands being a semantic mess, although they have improved somewhat over the years. I also didn't like how Github became some defacto self promotion thing. However, very few developers now don't use github to some degree in my experience (UK), bearing in mind so many new developers are/were being created each year compared to the past the more seasoned developers are becoming a vastly diminishing percentage.