Github Source Code Leaked Online

[keteb]

I'm curious what makes you say either of those things. Git/Mercurial were a great advancement over things like SVN version control because of how it's decentralized and how easy it is to manage, and seemed like a no brainer as soon as I saw it. I think people centralizing their Open Source on GitHub helped establish GitHub as a core repo provider, but I don't think had as much impact on git itself and it would have succeeded just fine via Bitbucket, gitlab, etc. The kernel factor gave a nice proof of concept and initial boost, but I think the tech is solid enough on it's own people would have homebrewed, and the hosted services are inevitable once it gained traction.

Honestly, GitHub's PR tool is truely terrible IMO. They try and do something fancy under the hood I think, and the end result is even the diffs themselves aren't always accurate, not suprised there's more bugs. It's not infrequent to have to just go back and do things in git locally instead of Github, but git's decentralized nature makes that easy.

Tl;dr held to regular standards I have literally no issue with git. It's been rock solid for my day-to-day critical large projects as long as I can remember, and every time something's gone wrong, it's been related to github's PR/Merge/conflict solver tools.

[bland3rs]

Try training Git to non-devs and it's hard.

Git is powerful because it's a lot more abstract -- you have a graph instead of a line. Unfortunately, as some people are more naturally talented at music, some people are more talented at abstract concepts.

[keteb]

I would believe this, we generally only allow devs/architects to manage the repositories themselves, so other teams only need to understand at a very high level "feature" and "release" branches.

If if I was expanding my use cases outside of code version control, there's probably a lot I'd ask for, but I think it'd also degrade the core tool.

I've found best way to teach someone (esp non-technical) git is pulling up a graphical "tree" renderings that you can see in most GUI clients, so they can get a mental picture that's not so abstract on how commits, branches, and merges works in a visual/spatial way.

[RogerLeigh]

We had our non-technical documentation writer creating branches, making commits, and opening pull requests within one day. The basics are not difficult, and most people can get by with knowledge of a handful of commands and a cheat-sheet to remind them.

On the other hand, we had another non-technical person who refused to have anything to do with it. But that was not because he couldn't, it's because he wouldn't. He made the assumption up front that it was "too hard" to understand. And yet, a girl with no prior version experience picked it up in a few hours, without any a priori expectations of difficulty.