The Basics of Git for Python Code

You may have heard of GitHub - a place that is home to well over 420 million repositories of code. In order to use GitHub to host, share, and collaborate on code, you need to understand how to use Git.

Git is a tool that allows developers to track changes of their code over time. You’re able to take “snapshots” of your code, work on different features/bugs (without having to rename each file something like script_v1_final.py), and collaborate with your peers.

This article is designed to be an all-inclusive tutorial of helping you get up and running with Git.

Table of Contents

• Key Terminology

• Getting Started with Git

• Creating your first Git project

  • Syncing it with GitHub

• Making your first commit

• Pushing Code to GitHub

• Pulling Code from GitHub

• Branching explained

• Commands to branch

Key Terminology

More often times than not, users who are new to Git often get lost in the terminology. Here’s a listing of terminology that is used here:

• Repository - A folder containing your project’s code.

• Commit - Create a “snapshot” of the code in its current state.

• Push - Synchronize your project on your computer with GitHub.

• Pull - Synchronize what’s in GitHub with your project on your computer.

Getting Started with Git

First, you need to have Git installed. The official Git installation instructions can be found on the Git website for Windows, Mac, and Linux.

Once you have it downloaded, setup your name and email using the command line:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

This will set your name and email for all of your commits in every repository.

Note: You can also set individual repositories by navigating into the repository and omitting --global flag.

Creating your first Git project

From here, you’ll create a project. Create a directory where you want all of your files to go and navigate into it:

mkdir my-project
cd my-project

Then, start your project by initializing git (this creates a .git folder in this directory):

git init

Now, you’ll be able to start making commits, pushing, pulling, and branching.

Syncing it with GitHub

Making your first commit

Now, create a few Python files and write some code. When you get to a point to where you want to “save your progress”, you’re going to want to check to see which file(s) you’ve edited by running the git status command:

git status

This will provide a listing of all of your files that have changed since the last “saved progress”.

Then, stage your file(s) by using the add command:

git add . # the period adds all the files

# OR add individual file(s) (based off of `git status`)

# assuming app.py is the name of the file in your repository.
git add app.py

Then, make a commit (“snapshot”) explaining the changes. This comment can be whatever you wish.

git commit -m "Initial commit with some initial code"

Note: the -m flag is important, as this allows you to make your descriptive message in-line. Without this, it’ll open an editor, which for some can be difficult to navigate.

Note: The quotation marks are also important - these must be double quotes.

At this point, you’ve essentially “saved your progress” in your code base. More advanced tutorials tell you to push your commits. While it’s not covered here, pushing is when you take the commits on your machine and put them into GitHub.

Pushing Code to GitHub

When you “push” code, you’re taking all of your commits (“snapshots”) and sending them to GitHub. Think of this as publishing your work for others to see:

So, let’s say we’re developing a website. You just finished developing some button aesthetics, making it much cleaner. You’ll run the 2 commands to capture the changes (which may look something like this:

[user@user]$ git add button.py
[user@user]$ git commit -m "updated button aesthetics"
[main (root-commit) af438e] updated button aesthetics
 1 file changed, 43 insertions(+), 26 deletions(-)
 create mode 100644 button.py

Up until this point, you can’t really share your updates with your team. So, you need a way to send it to them not through email. You’ll run the push command instead, which will take that commit (af438e) and send it to GitHub so your team can see the changes:

[user@user]$ git push

Pulling Code from GitHub

Great, now that your team can see your changes they need a way to bring it down from GitHub. They can do this by running the git pull command:

[user@user]$ git pull

Slightly modifying the diagram from above to demonstrate visually how this works:

Now, your team can see all of the changes that you made to your button. Similarly, if your co-worker pushed up a change that is a separate from your work on the button, you can run the git pull command to pull their changes to your local machine.

If you’ve ever wondered how projects are able to develop multiple features across multiple developers, the secret lies within Git branching.

Branching allows you to work on bugs and features simultaneously with your coworkers (or yourself) while not interfering with the main code base. Let me show you how this is done.

Branching explained

The simplest way to think of branching is just like a tree branch: for the tree to grow leaves, it needs to grow branches.

If the tree tried to grow leaves directly on its trunk, it would quickly run out of space, and the structure would become crowded and disorganized.

When the tree branches, each branch provides its own space to grow leaves, ensuring the tree can expand in multiple directions without interfering with its core structure.

Similarly in Git, branches allow your project to grow by creating isolated spaces for new features, experiments, or bug fixes, while keeping the main code base clean and stable.

Let’s take a project with a bunch of releases. The commits may look like this:

However, multiple users identified a bug within the most recent release.

It’s now your job to go in and fix this release. However, you don’t want to be tinkering with this code and messing this line of development up. So, you’ll want to “branch” out from the current code:

Then, you’ll make all the commits that are needed to be able to fix this bug. This can be as simple as one commit:

Once everything is tested and finalized, you can take this commit with the bug fix and put it back into the original code base and release a new version:

Commands to branch

To create a new branch and switch to it:

git branch bug-fix-v2.1.1
git checkout bug-fix-v2.1.1

For the latest versions of git, you can use switch instead:

git switch bug-fix-v2.1.1

Once you make all of your commits, you’re going to want to switch to the branch you want to put the changes into (in most cases, it would be the main branch):

git checkout main

And then run the merge command, which simply takes the code you had in the bug-fix-v2.1.1 branch and puts it into the branch you’re currently on (in this case, main):

git merge bug-fix-v2.1.1