Background

Before we learn about Git, let's talk about the reasons why Git exists.

The Master Copy

Before Git came into existence, people would work on software similar to how you have so far: they'd have a master copy stored on a server or disks somewhere, then as people needed to make changes, someone would be responsible for applying those changes to the master copy and ensuring everything still worked.

The simplest way of doing this is by overwriting the files with updated versions. This works okay if there's only one person working on a project on one computer at a time. But you may have noticed some issues with this when working on your own projects -- you have to always be aware of which version of your program is most up to date, so you don't accidentally modify older copies of your program. And if you ever happen to modify the same file in different places, it's a headache to try to combine both of your changes.

The more common way of doing this is with patch files, which are also called diffs. Diffs are generated by a computer program that compares one set of files to another and finds all of the differences. Here's an example of a diff file that adds the number 4 to a file containing 1, 3, 5:

--- 1.txt 2018-02-01 14:22:05.167313300 -0600
+++ 2.txt 2018-02-01 14:23:45.232070100 -0600
@@ -1,3 +1,4 @@
 1
 3
+4
 5

Patch files still require someone to merge them into the master copy, but since they only contain the changes and not the whole file, they're easier to share around. The smaller files also make it easier for other programmers to review the changes. Additionally, once the patch is applied, you can undo changes by applying the patch in reverse.

Version Control Systems

At some point, people started to realize that the task of merging changes into a master copy was pretty unfun and prone to human error. Imagine some of the following scenarios:

Two people gave you changes that conflict with each other
You're the only person with the master copy. You started renaming some of your folders and lost track of which folder contains the master copy
You realize that someone has introduced a critical bug a few versions back, but new features have been added since then
The person in charge of managing the master copy leaves the project

So programmers decided to write programs to do this work for them. These programs, called version control systems (VCS), focus on helping programmers keep track of changes to a codebase, also known as a repository. The most popular one in use today is called Git.

Git

Git is a type of version control system known as a distributed version control system. In a distributed VCS, each person working in a repository has a copy of every change ever made to the repository. Programmers make changes to their local copy of the repository, commit them to the repository, then push their copy of the repository out to someone else. When programmers want to get changes made by someone else, they pull the changes into their own copy of the repository. When pushing and pulling, git does its best to automatically merge the new changes into the local copy of the repository, but if it can't, it'll let you know.

GitHub

GitHub is a service that runs a Git server for you. This makes it easier to share changes -- rather than having to know the addresses of other computers with copies of your repositories, you can push to GitHub instead, and the other computers can pull changes from GitHub when they're ready. GitHub also provides a web interface for viewing the files in a repository and performing some common tasks on them.

Note: GitHub's role in the Git workflow is just to hold a copy of the repository in an easily accessible place on the Internet. There's nothing special about GitHub's copy of the repository -- Even if GitHub crashes, each person working in the repository has their own copy.

Git Workflow

Let's walkthrough a basic Git workflow using Pycharm and GitHub.

Creating a repository

Make sure you have an account on Github and log in.
Click the + in the top right and select New Repository.
Enter a name for the repository, then click the checkbox to Initialize the repository with a README.
Under Add .gitignore, select Python. If you're curious what this does, see the definition below.
Finally, click the Create repository button.

Now, you'll be taken to a page with your repository on GitHub. There are a few new words I'd like to point out here:

Commit: Git's word for a set of changes, like a diff. Your repository has to contain at least 1 commit, so GitHub automatically generated one for you containing a README file.
Branch: A branch is made up of a set of commits. Your repository starts off with a master branch.
.gitignore: Add files and folders to this file that you don't ever want to save to your repository. GitHub provides a list of common files for Python that you usually won't want to save to your repository.

Cloning a repository

Open up PyCharm.
On the Welcome screen, click Check Out from Version Control, then select GitHub.
Click Create API Token, then fill in your GitHub login information.
You should see the Token field populate. If you're not on your own computer, uncheck the Save Login box.
Back in your GitHub repository, click Clone or download. If the popup says Clone with SSH, click Use HTTPS.
Click the Clipboard button to copy the URL.
In PyCharm, paste that URL into the Git Repository URL field. Change the other fields if needed, then click Clone.
PyCharm will ask if you want to open the directory. Click Yes.

You should see the folder with your repository open on the left, containing the README file you just saw on GitHub.

Committing files

Let's make sure you can see the Version Control tab on the bottom. If you can't, click the square in the lower left, then click Version Control.
Open README.md and add some text to it.
Create a new file named "helloworld.py". PyCharm may prompt you to add some files to Git, go ahead and say Yes.
Add a print statement to helloworld.py that prints "Hello git".

In the Version Control tab under Local Changes, you should see two files, README.md and helloworld.py.

Click the Commit button (Under the Refresh button on the left)
Make sure the files you've changed are checked in the list of files.
Add a commit message to the commit, then click Commit.

Tip: A good commit can be described with a single-sentence commit message that doesn't include "and."

Viewing the log

Your commit is now in your local git repository, but it's not on GitHub yet. Click the Log tab next to Local Changes. You should see this screen:

Pycharm git log

Click the commit you just made. You'll see a list of files that were changed in the right panel. Click README.md and then Show Diff (the two blue arrows above). You'll see a comparison of the version of README in your commit against the version in the previous commit.

Demo: How to push/pull changes

Let's simulate working on a project from two computers by cloning another copy of the repository. Follow the steps under Cloning a repository again, but this time choose a different directory for the project. When you open it up, you'll notice that your changes aren't there, like you'd expect. Close the project and go back to the original.

Pushing changes to GitHub

In your project with two commits, go to VCS -> Git -> Push. PyCharm will show you that you're about to push commits to the master branch on origin. Origin is the default name for a remote git server, which in this case is GitHub. Click Push, then switch to GitHub and refresh to verify that your files have changed.

Pulling changes from GitHub

Switch back to the second copy of the project, and you should see the files before your latest change. Go to VCS -> Git -> Pull. The dialog shows that you're about to pull commits from origin into your local branch. Click Pull, and you should see a log item open up that displays any new commits that were pulled in.