1. Introduction¶

1.1. What Is Git?¶

Git ([gɪt]) is a distributed version-control system for tracking changes in source code during software development. [1]

The main benefits of Git are:

Coordination of the work among multiple users
Track changes in any set of files
Great speed & data integrity
Support for distributed workflows

1.2. Git Architecture¶

As mentioned before, Git is a distributed version-control system. If you want a graphical view of it, then it might look a little bit like this:

Distributed in this case means that every working copy of a repository contains the entire history of changes. Git doesn’t depend on a central server, as it can be used in a decentralised way. Thus, users can work with their repositories locally and offline.

1.3. GitHub, GitLab & Co.¶

When talking about Git, it’s important to make the difference between Git itself and all the collobration platforms.

While Git is the version-control system itself, collaboration platforms build up on it and only add additional collaboration features, such as:

Role based access control
Merge requests
Handling of issues
CI/CD pipelines

So collaboration platforms are mainly exist to enhance collaboration (obviously). They basically bring back the fun into collaboration projects.

We’re having a look at Collaboration platforms later in this workshop.

1.4. Comparison To Subversion¶

Here are the major differences between Git & SVN:

Git	SVN
Distributed Version Control	Centralised Version Control
Online & Offline Capabilities	Only Online Capabilities
Full Repository Clone	Only Working Copy (Trunk)
Easy Branching, Merging & Forking	Hard Branching, Merging & Forking
No Global Revision Number	Global Revision Number

1.5. Commit Early, Commit Often¶

In Git there’s a quite well-known paradigm:

Commit Early, Commit Often

There might be different interpretations out there, and there’s no “objective single truth”. However, it usually means that you shouldn’t be afraid to commit your changes early & often, even when you’re not finished (yet) with your whole change. The reasons for this are:

You want to split your change into smaller chunks
Smaller chunks of changes are easier to understand
Smaller chunks of changes are easier to revert
Smaller chunks can always be merged together later again (i.e. merge, rebase, amend, squash)
More commits you can access you need something you did a few minutes ago

Note

Please note in the main branches the commits might need to follow certain rules. But in your own branches, this rule is crucial.

1.6. CLI Tool¶

Git comes with an easy to use (I know, highly subjective) command line interface tool called git. The CLI tool is very well documented and you can always open up the help by providing the -h or --help flag:

git -h      # Shows the compact help for git.
git --help  # Show the full help (man page) for git.

Git as a lot of different sub commands. The help for those sub commands (e.g. log) can also be viewed by providing the -h or --help flag after the sub command:

git {SUBCOMMAND} -h         # Shows the compact help for subcommand.
git {SUBCOMMAND} --help     # Shows the full help (man page) for subcommand.

Hint

Also have a look at the output generated by functional Git commands, as they already give a lot of hints. For example when running git status, you might already see the most useful commands in the status output.

1.7. Workshop¶

This documentation provides an overview and introduction into Git and how to use it, especially in team setups. Since we’re using this documentation for our interactive Git workshop, and in order not to go beyond this scope, it won’t cover all Git features in full detail.

If you want to learn Git you should also refer to the Pro Git Book, written by Scott Chacon and Ben Straub, as well as the Atliassian Git Documentation.