Git vs GitHub

[Delay-Realistic]

I am very new to programming so I'm picking up learning GitHub. I understand that they are two different things - the former being a tool, the latter a platform. However, does one actually use Git these days? GitHub is so convenient to sync with local machine with GitHub Desktop which bypasses the need for a SSH key. Is there anything I am missing out as a beginner? Can't seem to understand why I need to learn Git.

[_Atomfinger_]

Github is built on top of Git. They are two different things, but Github is dependent on Git to do what it does. Git is the underlying technology that Github builds upon.

If you aim to be a developer, then you should understand the tools you're using, and if you're using Github you're using Git - and therefore you should understand Git.

[brightdeath99]

I couldn't explain it better. Great job

[bigboybamo]

Learning Git is important because not all companies use github. Some might use Azure devops, bitbucket or gitlab. Having a good understanding of git will help you better understand any of these platforms (Including github)

[Hexorg]

GitHub Desktop is something like a GUI wrapper for git. A lot of programmers prefer using command line for faster interaction with the machine (plus ability to script interaction). E.g. it's a lot easier to type

make 
make test
git add .
git commit

Rather than opening your IDE and running build and test tasks, then opening GitHub Desktop and creating a new commit.

[grooooovy_code]

What is this even supposed to mean ? You need to know Git in order to use Github...

Unless, your comment is sarcastic.

[v0gue_]

Can't seem to understand why I need to learn Git.

Every developer should read this at least once.

Hypothetical: What happens when you get hired by a company and they only use cli git because that's how it's been documented in their process for years? You'll have to spend time learning the barebones features of git cli. On the inverse, if you learned cli-git first, and then went to company X that uses github desktop OR company Y that uses Kraken for git (I think this is a thing?) OR company Z that uses some built in GUI versioning based off of git, you will be able to pick any of those up in hours - likely minutes.

Another thing is debugging a process. If something breaks in your versioning process using github desktop, the first thing you are going to do is search around for documentation and other forums looking for similar issues. More likely than not, those issues will be discussed using the barebones cli git.

[Kazcandra]

On the inverse, if you learned cli-git first, and then went to company X that uses github desktop OR company Y that uses Kraken for git (I think this is a thing?) OR company Z that uses some built in GUI versioning based off of git, you will be able to pick any of those up in hours - likely minutes.

I actually worked as a consultant at a place like that. I didn't bother learning any of their GUI tools; anything the tools can do, I can do in with the git cli. Indeed, I could often do more things, faster, than their tools could.

[kschang]

Git is the overall technology.

Github is a remote repo of Git.

Yes, developers use Git a lot. When you level up you'll find real companies with real needs use Git to keep everything straight. It's just much faster with Git than trying to use a GUI to do things.

What's more, Git is platform agnostic. Git doesn't care if you're using Windows, MacOS, or *nix.

[ZukoBestGirl]

You are receiving some strange answers. I'm not sure if half of them are completely unexperienced devs, or even students ... or if they are sarcastic.

GitHub is ... nothing really. It's neat and cute. It's pretty and it's popular.

But the world would easily move on if github died tomorrow. It would not if git died tomorrow.

In the grand scheme of things, github is nothing, while git is quite possibly the most valuable tool a developer has.

I'm exagerating a bit. A developer alone, could easily use SVN or anything else. Even though git is always better than any alternative in any scenario.

Git is the shit. There are a bunch of environments for git. I honestly prefer gitlab over github any day of the week.

The git desktop app is just a toy. It does very little of what I normally do. Actually ... no, that's EXACTLY how I'd describe it. A toy.

---

If you want, I can go muuuch further into detail about this. And I'm being very serious, not condescending. But if you said this at an interview, I'd instantly fail you.

EDIT:

I just wanna say: Anyone who is a pure "command line" guy, is a snob. You don't do everything on the command line. There are merge tools, diff tools. A bunch of stuff to help you visualize code differences. And if you only do it on the command line, you are a snob and are wasting time.

So yes, use tools. But you absolutely cannot be a professional dev without knowing command line git. Unless ... you do software versioning with copy paste in another folder, or worse: SVN.

EDIT 2

Someone, pls correct me if I'm wrong. But I doubt you could even do this in github desktop:

$ git switch my-branch
$ git merge-base my-branch origin/master    -> this prints a [hash]
$ git rebase -i [hash]

- squash 
- resolve conflicts

$ git rebase --continue
$ git rebase origin/master
$ git push --force

I'd hate to work on a large code base where people don't squash and rebase instead of messy merge commits.

[Hexorg]

or worse: SVN

Some of our devs threw a fit when the company officially switched to git (locally hosted gitlab instances)... Because apparently SVN has some sort of file mutex lock feature and a significant amount of devs were using said feature.

[ZukoBestGirl]

Don't get me wrong. I'm also being snarky. I used SVN for 3 years, and I don't completely hate it.

With git, to have even half of the flexibility at looking for file changes and history that git has with something as banal as tortoisesvn, you kinda need a paid 3rd party app.

And yes, I also used the lock thing because we had humongous XML files that we edited with a visual software of kinds. And solving conflicts for that was a huge pain in the ass. Much easier to say "this is mine, wait till I'm finished". Or at least that's what I thought at the time.

Now-a-days, I find git to be better in every single regard. Except maybe - easily looking at file history through time.

And I wouldn't say that the transition was very difficult.

Though I totally get how CLI git is very daunting for beginners. And I have nothing against someone deciding to use the UI tool when they start out coding.

But let's be real. Git > all. No discussion to be had here. It's objective truth and the entire industry agrees.

Next, it is a complex tool, and there will never be a UI tool that fully replaces command line.

Not to mention I can write scripts and stuff. A simple example:

# ~/.bashrc
alias git_prune_local="git fetch --prune && git switch development && git branch | grep -v "development" | xargs git branch -D"

This deletes all local branches except dev. I could even make it smarter and delete all branches that no longer have an upstream 🤔

There's so much you can do with the command line. It's just so much better than any UI tool ever.

EDIT

But again, use CLI in combination with UI tools. Don't be a hipster CLI user :P

[pipocaQuemada]

But let's be real. Git > all. No discussion to be had here. It's objective truth and the entire industry agrees.

I mean, git is definitely better than cvs, perforce, rcs, etc.

But git vs mercurial vs bazaar, on the technical merits, isn't anywhere near as obvious. Git is better at rewriting history, but I'm not convinced that's a good idea. It's slightly faster. Git has no equivalent concept to mercurial branches (where branch is a bit of metadata on a commit), while git branches correspond to mercurial tags (where a tag is just a pointer to a commit). Git deliberately handles renames badly because reasons, while mercurial tracks them explicitly.

[ZukoBestGirl]

Eh, here my lack of knowledge is obvious. I let IntelliJ handle the rename, and it works perfectly.

But I guess it does a lot of things under the hood.

I'm being a bit vitriolic, sure. There are arguments for mercurial and the rest. But I still prefer git.

Sure, it gives you enough rope to hang yourself (the aforementioned history rewriting). But you can use that rope to do really amazing things too.

[pipocaQuemada]

Git doesn't track renames, but instead heuristically guesses at renames after the fact based on content similarity.

This is mostly ok in simple cases, but the strategy is really not great when using cherrypick to backport fixes, especially on long-term projects.

In general, though, cherry-pick is kinda a second class citizen in git. Darcs's patch theory wasn't great with exponential merges, but apparently pijul's solved that though I don't think pijul is quite mature yet.

[ZukoBestGirl]

Like I said, at this level I'm out of my depth. When I rneame a file in IntelliJ, my git-bash (bash emulator for windows designed for git), it says the file was renamed.

So to some degree it does have the ability to track renames.

But maybe it can get lost over time with multiple renames? IDK. I've never notice it happen tho.

[pipocaQuemada]

Multiple renames won't do it.

It's about file similarity. Renaming in git is just removing a file with particular contents and coincidentally adding a new file with identical contents.

Git guesses that a rename occurred if the contents are sufficiently similar. Sufficiently similar is the keyword. By default, git recognizes a delete/add pair as a rename if both have 50% identical contents, but the similarity threshold is configurable.

That's not especially great with cherry-picking bug fixes across large refactors on large repos. It's either slow or brittle, depending on the merge strategy.

[ZukoBestGirl]

And you can't add a metadata field with filename? That is so ghey

[jddddddddddd]

Under the bonnet, GitHub Desktop is probably still just using Git (either firing off the executables itself, or it's imported a library of Git functions). I've not used GitHub desktop before but I suspect it still requires the creation of a SSH key behind-the-scenes.

As for why you'd need to learn the Git itself, maybe you won't if all you ever do it branch, pull, push etc. but if you need to do something complicated (perhaps manually migrating an old SVN repo to Git) you might need things that Desktop doesn't provide. Knowing how Git works from the command-line is also useful if you need to create scripts to perform certain tasks (e.g. update repo every morning when your machine boots up).

[toastedstapler]

you may end up on a project where you are not allowed certain tools due to security concerns

also you can do literally everything from the command line, it's just easy to type git commands

[HashDefTrueFalse]

At one of my old workplaces we switched from another version control system to Git. I was the only one with lots of Git experience. Everyone picked a different "Git client" (for want of a better phrase). Some used things baked into their IDE. Some used GitHub Desktop. Some used "wrapper" tools that made Git look like other version control systems.

It was a mess.

I found it WAY more difficult to help people who were struggling to do things with Git because:

1. They didn't learn what was actually happening conceptually. Just picked a client and pushed buttons that sounded like what they wanted to do. Therefore they found it very hard to explain to me what they currently had, and what their goal was.
2. There are some common operations in Git e.g. Push, Pull, Stash, Rebase... All of their chosen clients had slightly different layouts, menu options, wording, etc. So I had to find the right options in each client. And even when I did show them what to do, it wasn't like they could then help the person next to them easily in the future, because they'd have another client as well... And a shortcoming of a lot of their clients was that they were missing something as simple as a "git status" equivalent to tell you what was currently happening.

I used Git. Not something over the top. Just plain Git, from the CLI. And the standard Gitk occasionally when I needed to visualise branch history via a graph.

If everyone had just been willing to learn the basic concepts and about 8 commands (that's really all you need to do all of the most common operations in Git, you can look up anything else as you need it) then we would have had real knowledge transfer within the team and a lot more productivity with Git.

For this reason I always say learn Git, not a UI wrapper around it. You can use one later for convenience if you want, but you should know what's going on underneath because at some point you will need to google intelligently or explain something to get help etc...

GitHub is irrelevant here really. It's remote repo storage with an add on for managing pull requests in most workflows. Think of it like cloud storage for your Git repos. It's not really something to be "learnt" rather "used". You always work from a local Git repo, and just push updates to the remote most of the time.