Introduction

This post is part of a series about Git and GitHub.

In the previous post we looked at what Git and GitHub are, what problems they solve, and some key differences between them.

The goal of this post is to get you started working with Git as simply as possible.

To keep things simple we’ll narrow our focus in this post in three ways:

1. We’ll look at just Git - not GitHub. (We’ll look at GitHub in a later post.)

2. We’ll work locally - not remotely. (We’ll look at working with non-local files and repositories later.)

3. We’ll focus on the very basic commands - not advanced or intermediate or even quasi-basic commands. (There are other helpful resources for those.)

As previously mentioned, some aspects of Git are complex. But the basic commands for the core uses of Git don’t have to be.

For this post, we’ll just use Git for a simple form of version control so you can get started working with Git immediately.

For now, that means focusing on the most critical features.

• No cloning, no branching, no merging.
• No fetching, no pulling, no pushing.
• No rebasing, no reseting, no reverting, no rerereing.

You don’t need those features to get started working with Git.

Later you can learn to use those and many other helpful features as you need them.

Prerequisite knowledge

There are graphical tools for working with Git, but the typical means is through a shell. And this post assumes a basic working knowledge of the shell.

If you aren’t familiar with the shell, review Bash - Getting Started Working with the Shell for an introduction to that foundational topic.

How do I get started with Git?

To get started working with Git you need to complete just three steps:

1. Install and configure Git.
2. Establish a Git repository.
3. Use Git in the Version Control Cycle.

Step 1: Install and configure Git

Installing Git

The installation steps for Git vary, so check the “Installing Git” section from Pro Git by Scott Chacon and Ben Straub for your operating system.

Once you have completed the installation steps, enter the following command in a terminal to confirm successful installation.

git --version

If the installation was successful, you’ll see something like:

git version #.##.#

Configuring Git

Basic configurations

Configure Git with your user name and email.

Replace John Doe in the following command to set your user name.

git config --global user.name "John Doe"

Replace johndoe@example.com in the following command to set your user email.

git config --global user.email johndoe@example.com

Enter the following command to confirm your settings.

git config --list

Additional configurations

The following configurations are optional, but they can be helpful.

To change your default editor to Visual Studio Code:

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

To set main as the default branch name:

$ git config --global init.defaultBranch main

If it helps you to see the process, the Installing & Configuring Git video by Tower illustrates these steps.

If you get stuck or want additional information, see the “Getting Started - First-Time Git Setup” section from Pro Git for more details on Git configuration.

Step 2: Establish a Git repository

Start a Git repository

Since Git is a version control system for tracking changes in a set of files we have to tell it what files we want it to track.

Git tracks files in collections called repositories.

To initalize (that is, to start) a repository, first navigate in the terminal to the directory containing the files that you want Git to track. For this post, we’ll assume our project is in the /home/user/new-project/ directory.

Next, enter the command:

git status

If it is a directory that hasn’t been initialized previously, you should see the message:

fatal: not a git repository (or any of the parent directories): .git

That message tells us that Git doesn’t have a repository here.

To create one, enter the command:

git init

You should see a message like:

Initialized empty Git repository in /home/user/new-project/.git/

Now, run the status command again:

git status

Now you should see the message:

On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

You now have a Git repository and Git is watching for changes to the files in that directory. It isn’t doing anything to tracks those files yet, however.

The video Creating a New Local Repository by Tower illustrates this process.

Step 3: Use Git in the Version Control Cycle

Once you have a Git repository initialized, Git will watch for changes to files in that directory. To actually track those changes we will follow the steps in the version control loop.

Since we are using Git for version control this is where we will spend the majority of our time with Git.

Overview of the Version Control Cycle

At it’s simplest, the Version Control Cycle with Git is:

• Modifying files.
• Adding files to Git’s staging area.
• Committing the files in the staging area to Git’s repository.

You can repeat this process over and over as you make changes to your files and Git will save the history of those changes for you.

Since this can seem a little confusing at first, let’s discuss the steps of the Version Control Cycle. We’ll take a quick look at those steps and then go over the Version Control Cycle again in more detail.

Modifying files

Modifying files simply refers to the changes you would normally make to files. But now when you create, delete, or change any file in a directory that Git is watching, Git will see that the file has been changed.

It won’t actually track and save a record of those changes, however, unless you tell it to.

Adding files to Git’s staging area

For Git to actually track and save changes, you first need to tell it you want those changes saved. We do that by adding files to Git’s staging area.

If we don’t add files to the staging area Git will see that the files have changed, but won’t record those changes.

Committing files to Git’s repository

After we have modified files and then added the files we want tracked to the staging area, it is time to tell Git to make a record of those changes. We do that by committing the changes to the Git repository.

The Version Control Cycle in action

That is the Version Control Cycle:

1. Modify files.
2. Add the files to Git’s staging area if we want Git to record the changes made to those files.
3. Commit the changes in those added files to Git’s repository.

That may still seem abstract, but it is a core concept, so let’s look at it in action with some examples:

• The video Staging & Committing Changes by Tower demonstrates the Version Control Cycle.

• And the video Git Introduction for Beginners: Git Repositories by KodeKloud (starting at 1:10) provides another look at this process.

• The video git init and git add - Git and GitHub for Poets by The Coding Train illustrates this with additional explanation.

Review of the Version Control Cycle

Let’s take one more look at how to manage the Version Control Cycle with Git.

From the “Getting Started - What is Git?" section from Pro Git:

Git has three main states that your files can reside in: modified, staged, and committed:

• Modified means that you have changed the file but have not committed it to your database yet.

• Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

• Committed means that the data is safely stored in your local database.

This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.

And from the “Git Basics - Recording Changes to the Repository” section from Pro Git:

Typically, you’ll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record.

Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.

Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven’t edited anything.

As you edit files, Git sees them as modified, because you’ve changed them since your last commit. As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.

Using the Version Control Cycle

Now, let’s work through the Version Control Cycle ourselves.

Version Control Cycle Example - Cycle 1

First, make sure you are in the directory of your project and that your Git repository is initialized as described previously.

Modify files (Cycle 1, Step A)

Next, we need to modify one or more files.

We’ll start by creating a new index.html file:

touch index.html

We’ll add our first line to the file.

echo "Hello World" > index.html

Since we initialized a Git repository for this directory Git is already watching for changes. It isn’t doing anything with those changes, but it is watching for them.

You can confirm this by entering the git status command:

git status

You should see the following message:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	index.html

nothing added to commit but untracked files present (use "git add" to track)

Add files to Git’s staging area (Cycle 1, Step B)

As the message indicates, we need to add that file for Git to track it’s changes. Let’s do that now:

git add index.html

Run the git status command again:

git status

You should now see the message:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   index.html

Now our file is staged, but the changes to it still aren’t committed to Git’s repository.

Committing files to Git’s repository (Cycle 1, Step C)

Finally, we’ll enter the command to commit those changes:

git commit -m "Initial commit"

-m "Initial commit" - This tells Git to attach the message “Initial commit” to this commit’s history.

You should see a message like:

[master (root-commit) a4b6f1d] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 index.html

Run the git status command again:

git status

You should see the message:

On branch master
nothing to commit, working tree clean

That is one loop through the Version Control Cycle.

Version Control Cycle Example - Cycle 2

You’ll likely spend most of your time with Git using these commands in this cycle, so let’s work through it again.

In our first pass we didn’t use well-formed HTML, so let’s fix that.

Modify files (Cycle 2, Step A)

First, we’ll edit our index.html file to the following:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Hello</title>
</head>
<body>
    <h1>Hello World</h1>
</body>
</html>

Now, run the git status command:

git status

You should see the following message:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

Add files to Git’s staging area (Cycle 2, Step B)

As before, we need to add this file to the staging area in order for Git to record our changes to it’s repository:

git add index.html

Run the git status command again:

git status

You should now see the message:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   index.html

Again, our updated file is staged, but the changes to it still aren’t committed to Git’s repository.

Committing files to Git’s repository (Cycle 2, Step C)

And again, we’ll enter the command to commit those changes with a clear commit message:

git commit -m "Improve format of index.html"

You should see a message like:

[master 2a8e5e7] Improve format of index.html
 1 file changed, 12 insertions(+), 1 deletion(-)

Run the git status command again:

git status

You should see the message:

On branch master
nothing to commit, working tree clean

That is our second loop through the Version Control Cycle.

Version Control Cycle Example - Cycle 3

Let’s work through another example and modify more than one file.

This time we’ll add style.css and link it to our index.html file.

Modify files (Cycle 3, Step A)

Create the style.css file.

touch style.css

Add some content to the file.

echo "body {background-color: gold;}" > style.css

Now, we’ll update the index.html file to link to the new css file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
	<link rel="stylesheet" href="style.css">
    <title>Hello</title>
</head>
<body>
    <h1>Hello World</h1>
</body>
</html>

Run the git status command:

git status

You should now see the message:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	style.css

no changes added to commit (use "git add" and/or "git commit -a")

Add files to Git’s staging area (Cycle 3, Step B)

Now, we need to add both files to the staging area in order for Git to record our changes to it’s repository:

git add index.html style.css

Run the git status command again:

git status

You should now see the message:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   index.html
	new file:   style.css

Yet again, our updated files are staged, but the changes to them aren’t committed to Git’s repository.

Committing files to Git’s repository (Cycle 3, Step C)

Finally, we’ll enter the commit command with a clear commit message:

git commit -m "Add style.css and link index.html to it."

You should see a message like:

[master b6baf2a] Add style.css and link index.html to it.
 2 files changed, 2 insertions(+)
 create mode 100644 style.css

Run the git status command again:

git status

You should see the message:

On branch master
nothing to commit, working tree clean

That is our third loop through the Version Control Cycle

Version Control Cycle Example - Summary

That is the Version Control Cycle.

There is much more that Git can do generally, and even in this simple workflow specifically. But that cycle is the basis of working with Git. If you followed along, you are already using Git for version control of your project with just these few commands.

A note on the git add command

As you might have already found, the git add command is used to accomplish several things.

This note from the “Git Basics - Recording Changes to the Repository” section from Pro Git offers a helpful way to think about this important command:

git add is a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as “add precisely this content to the next commit” rather than “add this file to the project”.

More useful commands in the basic Version Control Cycle

While we have touched on the basic commands needed to start using Git in the basic Version Control Cycle, there are some additional commands that can be helpful even at this early stage.

To add all modified files at once, without having to list them individually you can use the following:

git add .

To add all modified files that match a particular pattern you can use a wildcard (*):

git add *.html

git add article0*.html

git add app.*

To amend the last commit message:

git commit --amend -m "New commit message"

To see a log of commits in the current repository:

git log

To see a log of of only the last 2 commits in the current repository:

git log -2

Ignoring files

You are likely to also find files that you don’t want to include in your Git repository nor to even see tracked by Git. You can tell Git to ignore those files with a .gitignore file.

The video Ignoring Files by Tower demonstrates how to use a .gitignore file.

The “Git Basics - Recording Changes to the Repository” section from Pro Git covers the topic with additional detail.

And as that section of Pro Git points out:

GitHub maintains a fairly comprehensive list of good .gitignore file examples for dozens of projects and languages at https://github.com/github/gitignore if you want a starting point for your project.

Next steps in learning Git

There is much more to learn in Git. This introduction elides all but the most basic features.

For more detail on just these first basic features, the video Git Tutorial for Beginners by Programming with Mosh is particularly helpful. It is a structured and thorough look at just these foundational steps.

To find a curated list of many more resources for learning about Git you can review our Git and GitHub Topic post.

To move to the next topic in this series take a look at Getting Started with Git Branching and Merging.