1. Git is a Source Control Management Tool/Version Control System.
Git Introduction
Git is a Source Control Management Tool/Version Control System.

2. Source Control
A means of recording what has happened to your source over time
It gives you a (live) history.
Earlier SCM’s.
RCS was an early Version Control System, it did things one file at a time
Microsoft Visual Source Safe
VCS, Subversion
Liked RCS, used it a lot through the early 90’s, Also used VSS a lot, apparently it is likely to corrupt your data and is not recommended.

3. Source Control
Uses
When something breaks, it is possible to compare the current version, with an earlier version that worked, and find what where things went wrong. Especially if some time has passed, or someone else is now maintaining the project.
A good way of locating bugs apparently, is to review sections where lots of changes have been made in the past.
It is like another external memory aid, while you can probably remember what you changed this morning, what happened 2 weeks ago, less likely.

4. Git History
Git was created by Linus Torvalds (with help), when the SCM they were using became unfree for use by the Linux Kernel Team. Its initial release was in a very short timeframe. It has been getting better ever since.
It has become huge.
Linus gave a talk about this and generally caned CVS, and Subversion.
Transcript:

5. Comparisons Git is a Distributed SCM
 Many of the older network SCM’s were centralized
 When you clone a repository using Git you get most all of the history of the project and can see what happened (and why), and it is effectively a Clone, other people can clone yours and get the same stuff. You can share changes privately with other people.
Whereas with say traditional Subversion, if you aren’t connected to the central repository you get almost nothing.
RCS you really need to be working on the same filesystem.
You were able to drop RCS files directly into CVS and they would work.

6. Comparisons
Git creates a single (usually) directory called .git in the top level directory of the project, that has the entire history of the project within it.
Cf. Subversion, which has a .svn directory for each directory in the project. (And they largely just contain the current server version of that directory)

7. For Single Users Source Control is recommended.
Git happens to be very good.

8. Git Storage Git is like a miniature filesystem.
As Linus is a File System kind of person, Git was made in a File System manner
It stores content, rather than changes to individual source files. With a structure on top of the content to link the content files back to their file names, and history.
Each file that is checked in is stored in its entirety with some of the Git attributes. (Compressed with ZLib). With its name within the repository being the SHA1 hash of the uncompressed file
These Loose files can be packed, which can use delta compression to give much tighter storage.
Older SCM’s would store the changes as Diffs, and these diffs would be applied to the current version to get the older version. Works well with text files, less well with binary files. Renaming tended to be hard work
Renaming of a file in Git, the file is removed and added with its new name, but having the same Hash gives it a fair indication the file was renamed.

9. Loose files
To show the contents of the file git cat-file -p 58e2592d61bc45e8d8f6f7a046f30c09c7ec3e1a
this is a test
 File was called objects\58\e2592d61bc45e8d8f6f7a046f30c09c7ec3e1a
 Can also use zlib extraction.
openssl zlib -d -in e2592d61bc45e8d8f6f7a046f30c09c7ec3e1a
blob 16 this is a test
 pigz can also be used to view the raw file content (decompressed).
 Also:
openssl zlib -d -in e2592d61bc45e8d8f6f7a046f30c09c7ec3e1a | sha1sum
gives 58e2592d61bc45e8d8f6f7a046f30c09c7ec3e1a

10. Cloning a Repository git clone https://hostname/path
You wind up with a clone of the original.
You can check things out, etc.
You can track changes to branches in the original source (origin)

11. Branching and Git Workflows
This seems to be a promoted feature.
Branches are very light weight and allows you to easily create new branches for tasks to work on, and then merge your new code in to the main branch (Master). Allows you to run multiple parallel branches.
Handy if working on a task for next release, then get an urgent fix requirement to be applied to the current release.
You do need to put some effort and practice into this to see how it works, and how it might be useful in your work flow.
Usually the Master branch is called master.

12. Git Workflows
Centralized Workflow
Feature Branch Workflow
This seems fairly simple but useful. All features are made in a special branch just for that feature and merged into the master when complete.
Gitflow Workflow
Like feature branch but multi-level and more structured
Forking Workflow
Often used with Pull Request below

13. Pull Request
Often used with GitHub to give work you have done on a public project to the maintainers.
Clone the Project, make and test the changes locally (in a branch)
Make a Fork of the public project which creates a writable fork of the project.
Push your new branch to the Fork.
Notify the maintainer, by creating a Pull Request. (GitHub has a Pull Request Mechanism) Which indicates the branch you have created (and want them to merge in) as well as the fork repository.
There will then likely be some back and forth communications between the maintainer and yourself before they will accept your pull request.
You don’t need to host a readable repository.
Have read of pull requests, and was never really sure what/how.

14. GitHub Etc GitHub seems to be the best known, there are others.
GitHub seems to be the best known, there are others.
Public hosting for source files in a Git Repository
Also does private hosting in the same infrastructure

15. Commit Messages
Found a recommended Commit Message format in Pro Git R2 pp156, which looks sensible
 Single Line of up to about 50 characters which describes the changeset concisely.
Blank Line
More detailed explanation, including your motivation for the change and contrast its implementation with the previous behavior.
A template (Originally by Tim Pope) is included in the book.
Mentions, -ability of the Change

16. Git Index/Staging Area
Git has an index, or staging area.
With some GUI Tools it is often not seen, but sometimes used.
Can commit just a few files, (or even selected sections of files is an option) rather than the entire set of changed files
Means you can stage changes,
Break a set of disparate changes that you have made into a set of commits.

17. Misc Stuff Putting your .git folder elsewhere.
git init --separate-git-dir="PathToGitRepo"
Don’t Use Binary DFM files. (Mainly older Delphi’s)
I seem to usually wind up with a Git Library, I could put my git repositories into a separate directory, and add it to that library, that way things like file history would include those files.

18. Tools (Gui)
git gui Check in files, etc
gitk Look at file history

19. Gnu/Linux Tools
Git (on Windows) also includes a bunch of Gnu/Linux tools
I don’t normally have them in the path but have a batch file that will put them in the path when I want them.
Setgit.bat
path C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin;%PATH%
Mine has no man pages, Use Internet.
 I use
tar occasionally awk/gawk sometimes dd is good, but I tend to use a different one.

20. Gnu/Linux Tools It has a bash shell, so can run bash scripts.
It also has perl.
Some of the tools included require you to be running bash before they will execute (These tools have no extension, and are likely to be perl or bash scripts)

21. 3rd Party Tools Atlassian’s Git client SourceTree
ASP.net GIT web host: WebGitNet
BFG Repo Cleaner to remove files you should not have put into GIT.
Tortoise Git
Libgit2 a C Library of all the Git Core Functions, which you can then embed in your applications.

22. Books Pro Git V2, is downloadable from: https://git-scm.com/book/en/v2
Git Notes for Professionals:
control-system-62b17dd37742

23. Included Documentation
There is a bunch of included html documentation for Git. (less so for the other common Gnu/Linux tools)
C:\Program Files\Git\mingw64\share\doc\git-doc