Git 101: Everything You Need to Know to Get Started with Version Control

In this post, we’ll cover the absolute, bare-bones basics of Git, so you can get up and running as quickly as possible. Although Git is very powerful, and has a lot of commands and options, you only need to learn a few of them to start using it to keep track of your own projects. Once you are comfortable using Git on your own, it will be easier to learn how to use it to collaborate with others, and you can add more complex Git commands to your repertoire.

It is important to note that this article is for absolute beginners who want to start keeping track of changes to their own code. The article only covers a few of the most basic commands, and is meant for those who are just starting to use version control. It does not contain any information on how to use git for collaboration (that will be coming in a later article!).

This article is a long one, so for handy reference, here’s a table of contents:

• What is Git?
• Why should I use it?
• Download Git
• Configuring your user settings
• Creating a repository
• Using a .gitignore file
• Tracking changes to files
• Making commits
• Rolling back changes
• Pushing your code to the cloud

What is Git? 

Git is a Distributed Version Control System (DVCS) used for software development. It was created by Linus Torvalds in 2005, and has become one of the most popular version control systems in the world.  Git allows multiple developers to collaborate on the same codebase, making it easier to track changes to code, switch between different versions, and merge changes together from multiple sources. With Git, developers can work on their own copies of the codebase, and merge their changes into a shared main branch when they are ready.

Why should I use it? 

Version control is an essential tool for modern software development, and Git is very popular!  It is used by developers and organizations of all sizes to manage their code and collaborate on projects.  You can start using it to track changes in your own projects, even if you’re not collaborating with anyone else.  It’s a good idea to use Git to track changes in your own projects, so that you can practice the commands and get used to using version control.  You can also use Git to push a copy of your codebase into the cloud, so that you have a backup copy of your code if anything happens to your computer, or if you’d like to share your code with others. 

Okay, I’m ready… what do I do?

You can download Git from git-scm.com. It is available for Windows, MacOS, and Linux, and installation instructions are on the website for each operating system.

Configuring your user settings

Once you have Git installed, you’ll need open a terminal or shell window and use two commands to set your user name and your e-mail. Git uses these to “sign” your commits, so choose a publicly-appropriate name and valid e-mail address.

git config --global user.name "Your Name"
git config --global user.email youremailaddress@example.com

You will also want to set your default main branch name to “main”. Historically, this branch has been called “master,” and Git will still default to that name. Most online code repositories now default to the name “main”, though, so you’ll want to use that for the name of your main branch.

git config --global init.defaultBranch main

It’s also a good idea to tell Git which text editor you want to use if you ever need to add or edit a message. If you don’t configure a text editor, Git will use the default editor on your system, which is usually vim (a text editor that runs in the terminal/shell). Vim can be very confusing for even experienced developers, so it’s best to chose an editor that you’re familiar with. You can find a list of commands for specific editors at this link; the example below sets up Visual Studio Code.

git config --global core.editor "code --wait"

Important note: if you are using Windows, you must use the full path to your chosen editor’s executable file. Visit the link above to see examples.

Creating a Repository

The first thing you’ll need to do to use Git is create a repository, often called a “repo”.  A repository is where all of your code for a particular project will live; Git can see all the files in the repo and will track all of the files created and modified inside of it. It is recommended that you use one repository per project, instead of putting several projects inside of one repository.

To create a repo, open a terminal or shell window and navigate to the directory containing the files you want to track, and type “git init” at the command prompt:

git init

The “init” command sets up a git repository for the current directory, which allows Git to track the contents of the directory as well as any subdirectories inside of it. 

If you view the directory in the file explorer, you should see a new hidden directory inside of it named “.git”.  This subdirectory is where all the files Git uses to track changes in your project live.  

Using a .gitignore File

A .gitignore file is a configuration file that tells Git which files and directories should be ignored when tracking changes in a project. It is very useful for excluding files that are not necessary for the project, such as temporary files or build artifacts, and can help to keep your repository clean and organized.

Here are the steps to use a .gitignore file:

1. In your repository, on the same level as the .git directory, create a new file called “.gitignore”.
2. Open the .gitignore file with a text editor, and add the names of any files or directories that you want Git to ignore. Each entry should be on a separate line, and you can use wildcards to match patterns of files (e.g. “*.log” to ignore all log files).
3. Save the .gitignore file, and commit it to your Git repository.

You can find ready-made .gitignore files for many programming languages online if you don’t want to create your own. (Pro tip: if you are doing .NET programming, and using .NET Core 3.0 or higher, the command dotnet new gitignore will generate a standard .NET .gitignore file for you!)

Once you have a .gitignore file committed to your repository, Git will automatically exclude the files and directories in it from future commits. 

If you need to modify the .gitignore file later, you can edit it and commit the changes like usual–just keep in mind that the .gitignore file will not apply to any files or directories that exist in the repository that are committed before the .gitignore file is committed.  I recommend adding a .gitignore file before you start committing to your repository, so that you don’t accidentally commit build artifacts or temporary files with your first commit. 

Tracking Changes To Files 

Once you have initialized a repository, you can add files to staging.  When you make changes to files in a Git repository, those changes are not immediately added in the next commit. Instead, you need to manually add them to the staging area before you can commit (save) them.

Staging is like a buffer between your working directory and what is committed to your Git repository. When you add changes to the staging, you are telling Git that you want to include those changes in the next commit. Staging allows you to review and decide which changes to include in your next commit.

To add a file to staging, run the command “git add <filename>”.  You can also add all of the changed files in the current directory and all subdirectories to staging by using the command “git add .”.

git add "file.txt"
git add .

If you want to see what files you have staged, and what files are not staged, you can run the status command:

git status

Making Commits

After you have added files to staging, you can make a commit to “save” the changes to your repository.  You can think of a commit like a save point in a video game; it’s a spot in your repository’s history that you can come back to.  A commit will take a snapshot of your repository based on the files you have added to staging. 

git commit -m "a descriptive message"

To make a commit, run the command “git commit -m ‘<commit message>’”.  (The -m flag is very important; if you forget it, the terminal will open vim and ask you to create a message, which can be very confusing for new developers.)  The commit message you write should describe the changes you made in that particular commit. 

Once you have made a commit, you can keep working on your code, and when you’re ready to save again, simply add the files to staging and make another commit!  Git keeps track of all the commits for you, and if you want to throw away your changes and start fresh, you can roll your code back to a previous commit. 

Rolling Back Changes

To look at your 10 most recent commits, use the command “git log -n 10”. (To look at all of your commits, use “git log”–but if you’ve made a lot, you’ll have to scroll through all of them!)  Each commit will have a unique SHA identifier listed: 

To roll back to a commit, copy its SHA and use the command “git reset –hard <SHA>”.  Be very, very careful doing this, because you will lose all your changes made after that commit!  (There are ways to not do this, but they are more advanced.)

Pushing Your Code to the Cloud 

A very popular place to store Git repositories online is GitHub (github.com).  Sign up for a free account, and create a new repository on GitHub.  The next step will be to “push” a copy of the repository on your computer (referred to as a ‘local repository’) to your repository on GitHub (referred to as a ‘remote repository’). 

To let your local repository know about your remote repository, use the “git remote add <remote_repo_name> <URL>” command.  Traditionally, the main remote repository is known as “origin”. 

git add remote origin https://www.github.com/myusername/mytestrepo.git

Before you can push your code to GitHub, you will need to set up an access token or install the Git Credential Manager (recommended). This is how you will sign in to GitHub when you push your code from the terminal/shell. Once it’s installed and configured, you don’t have to do anything special–a window will automatically open and walk you through the sign-in process.

Once you have let your local repository know about the remote repository, you can push your commits to the remote repository using the “git push <remote_repo_name> <branch_name>” command.  Replace <remote_repo_name> with the name of the remote repository (usually “origin”), and the <branch name> with the name of the branch you want to push (in our simple case here, “main”). 

git push origin main

That’s it!  Git will push a copy of all your codebase and commits to GitHub, where they will be safely stored online. 

---

There you have it–the very, very, very basics of Git. You can send anyone the link to your GitHub and if you set the GitHub repository to “public” they can read your code, and even copy it to their own computer and run it–that’s a great way to ask for help with something. If you make a mistake, or want to go back to a previous version of your code, you can do that, too! In a future blog post, I’ll write about using branches to maintain different versions of your code, so you can try things out without having to roll back and lose any changes you’ve made, but for now, you know enough to get started making commits. Once you have the add, commit, and push commands down, you’re ready to start adding commands and using the more complex features of Git, so keep an eye on my social media for when the next Git guide drops!