Erk... I thought you'd given it a go for some reason. I'll start from the top.
First of all, Git is a version control system. If you're not familiar with these they're basically like having an accounts ledger, except instead of accounts, it's a ledger full of all the changes made to your code. You can go back and look at code at any given point in time, which can be incredibly useful. Different styles of version control exist, of course, but Git lends itself to a decentralized workspace. With Git, everybody working on a project has a copy of the ledger, and at any point you can revert your code to a different version easily, or compare different versions to see what's changed.
A repository contains all past and present code, plus all the notes that go along with them. Let's say I have a repository called "Hello World" with a file called "main.cpp". "Hello World" currently has no code, but then I write something in "main.cpp" then 'commit' my change to the repository. That 'commit' will update the repository such that "main.cpp" has the code I've written, plus a log of the change. If I then 'commit' a new change where I refactor the code there will be a new account describing what code was added and what was removed. If you view "main.cpp" in the repository you'll just see the new, refactored code, but you can go back over all the previous versions and see how it's changed over time.
A branch can be a bit deceptive. If we tried to use a tree metaphor we'd end up getting really confused, so it's best to think of a branch as more of an "alternate dimension". A repository, in this sense, would be a multiverse, containing all possible worlds. Each 'branch' is a universe which branches from our repository. The central branch, aka the 'master' or 'origin' branch, would be the world we occupy, while each new branch is a path our origin can take. We build a branch from the origin, change the code, then we merge our branch with the origin such that they both contain the same code.
GitHub gives us a platform to manage our repository. Your local copy is uploaded to the cloud, where every contributor can 'fork' the repo, copying it, essentially. They'll keep this up to date themselves by regularly merging changes from the original, and send the changes they make back through a 'pull request' to your repository. Pull requests are a commit that's waiting to happen, which allows the code maintainers to vet changes before they're introduced. Let's say you write a header for "Hello World" and place it in a new branch in your copy of the repository called "new-header". When you've finished writing this header you then make a 'pull request' of the origin, or commit to it directly if you have the right to. Now, the master branch has a new commit (new code) and all forks will be able to synchronize the changes to their master branch locally.
GitHub Desktop provides a GUI that interfaces with GitHub.com and provides common Git commands so you can make pull requests (PRs), commits, branches and repositories easily, switch between branches, compare revisions or branches or even different bases. For example, say Bob is working on a "gui.cpp" in his branch "hello-gui" but was also tinkering with his own "main.h" in "main-header-test". He could sync "hello-gui" easily, but "main-header-test" would throw a warning about conflicts that would need to be resolved. GitHub Desktop can do this automatically (I would never trust this, personally) but it also provides a merged text file with markers to show where the conflicts are and what the changes comprise. You can also merge changes across branches under different users' repositories, or from PRs to the main branch or any other branch you choose. You can rebase a branch to any earlier version; for example, you may rebase a branch of master called "last-week" that reverts all the commits since seven days ago, or a year ago, and compare this to the current master to see the changes. you could compare the changes in one PR which changes a thousand lines of code to another PR of a thousand with some overlap. Using the website you can directly browse the repo at any given point in time based on a particular commit and view full file histories in a convenient format. It's probably doable with Git BASH and GitHub Desktop, but the website is very convenient so I've not bothered looking into it.
Finally, Git BASH is an emulator of BASH, a UNIX/LINUX... thing. I know as much about that stuff as you did about GitHub.
I'd call it an alternative console because you can use it to run Git from the command line. Git is a UNIX tool, so I guess it makes sense. I just google what I need when I need it and muddle through. Theoretically you can do everything you can do in GitHub Desktop and GitHub.com plus a whole host more through BASH, but if you don't speak UNIX you can end up seriously confused.
Whew. I hope that answers some questions and helps a little!
Edit:
Taken a look over the source with a view to modifying LCS to accept key configuration. It's frightening. Forget I asked.