Intro
This post is a follow up to my previous article, if you are starting here, think about going back to getting started .
Now that you understand the types of problems that Git solves, it is time to start learning Git’s interface. This the hard part of learning Git, since Git's commands (checkout, rebase, etc.) describe the actions they perform on Git's internal data structure , rather than the logical operations the user wants to perform . The end result is that the UI is confusing if you don't take the time to learn Git's internal workings.
There's a lot that you can do with Git, so when just starting off, it can be helpful to think in terms of use cases. In this article, we will walk through how to make changes in a project, which should be enough for you to start working on your own. We will also walk through how to browse history in Git and we’ll use that process to confirm that the changes we checked in during the previous step were actually saved. Lastly, we are going to spend some time on undoing things &mdash that way, if you realize that you've made a mistake, you have the tools to undo it.
Assumptions
Before we get too far down the line, we need to address how we will be using Git. There are a number of different Git GUI interfaces. Many of them (e.g. GitExtensions, Magit, Tower) are quite good, and a lot of beginners start off with one of them. That being said, I am going to be teaching to the command line.
I prefer to teach the core functionality of Git using the command line, because all the commands used are portable, meaning you should be able to use the information presented here to whatever tool you will be using (whether that be a complex GUI application or the integrated Git tools in your favorite integrated development environment) and quickly be able to work.
The same can not be said going the opposite direction, as different GUI programs tend to simplify Git in different ways, which makes teaching the concepts more difficult. If you want to use a GUI for this tutorial, that should be fine, but the examples will focus on command line Git.
Setup Instructions
Since we will be using the command line, you should know how to navigate the file system and call programs. If not, spend some time getting familiar with the terminal, possibly starting with something like this article from the Programming Historian . I will also not be covering how to install Git and set it up on your machine. If you are interested in that topic, start here .
Basics
Initializing a new repository
The first step in using Git is to create a new repository. A repository is just a "project" (or a collection of related projects) that Git is versioning. When developers talk about "contributing to a repository" all they mean is that there is a project hosted somewhere, and they have changes committed to it.
You can set up a new repository on your machine anywhere you like. Start by creating a new folder somewhere (I am going to use ~/Development/TestingGit/). Then open your terminal (if you haven't already,) navigate to the directory you just created, and type git init. You should see output like this:
git init
Initialized empty Git repository in /home/zachery/Development/TestingGit/.git/
Obviously, the path that you see will probably be different, but it should match the folder to which you navigated.
Now that you have a shiny, blank repository (or "repo" for short) lets start by putting something new in there. For our purpose, we are going to just version a text file called "myFile.txt". Go ahead and create that file now, and inside it put the text "Hello, world!"
Once you have saved your file, go back to your terminal and type git stage *; git commit -m "Initial commit".
Adding/committing
Now that we have our repository set up, let's examine what we just did further. In Git, the normal way to make changes is to package them up in a neat little box and then seal the box. Staging (Accomplished by the command git stage) is the process by which you add changes to the opened box. Running git stage moves changes into the "staged" status. Things in the staging area are "sealed up" when you run the git commit command.
You might reasonably wonder why we make the distinction between staging and committing. For now, it's reasonable to think about staging like checking boxes in a form UI where each file that is staged has it's check box marked so it will be committed when you type git commit. Later articles that will look at more advanced usages of the staging area as well as shortcuts to skip staging entirely in certain situations!
Viewing log
The next obvious question after committing is "did it work?" The way to see if your commit was created is to use the git log command, which shows the history of commits. That means that you can browse the changes that you and anyone else working on your project have checked in. To make this a little more clear, lets add "It's a lovely day!" to the end of our file and stage and commit that. Your log should now look like this:
commit f6e67dfffa3faa36aee43fc53f31de698f200441
Author: Zachery DeLong <[email protected]>
Date: Thu Mar 30 20:31:37 2023 -0400
Adding a line to my file
commit b0119b6ccc42ddb9dddb313ca1858efdad5b62ea
Author: Zachery DeLong <[email protected]>
Date: Thu Mar 30 20:09:38 2023 -0400
Initial commit
Notice a few things about this. We have two commits now, and for each commit Git is showing us four things: a hash, the author of the commit, the date and time the commit was made, and the message we supplied when we made the commit.
The hash is the first thing that is shown in the log. It's a seemingly random string of characters and numbers that is intended to uniquely identify a particular commit. This turns out to be extremely handy, because you will find that you often need to refer to a particular commit (to undo it, or even just to look more closely at its contents) and these hashes save us from having to type out the entire message when searching.
The next field in the log is the author. Obviously this is the person who made the commit. Then after that is the date and time the author created the commit.
Lastly, we have a message that the committer wrote. Usually developers will use this field to describe their change set so that other people who need to look through the history for something can get an idea of why they made the changes they did.
Getting detailed about commits
Now how do we see the changes in a particular commit? If you only want to see one commit, git show [hash] should show the changes.
commit f6e67dfffa3faa36aee43fc53f31de698f200441 (HEAD -> master)
Author: Zachery DeLong <[email protected]>
Date: Thu Mar 30 20:31:37 2023 -0400
Adding a line to my file
diff --git a/myFile.txt b/myFile.txt
index a5c1966..7e10e53 100644
--- a/myFile.txt
+++ b/myFile.txt
@@ -1 +1,2 @@
Hello, world
+It's a lovely day
Notice that this example looks a lot like the log we looked at above, but there’s now a section labeled “diff.” This is the small change that we checked in in this commit. A lot of the information here is duplicated, but what it is telling you is that it is showing the difference between two commits in one particular file (a/myFIle.txt and b/myFile.txt) and that a line preceded by a - means something was removed and a line preceded by a + means something was added. notice that in this case, we added one line ("It's a lovely day").
There are other ways to see larger change sets of different commits shown against each other, but we can get into that later
Undoing things
If you have made changes that you aren’t happy with, you can use git restore [path-to-file] to “undo” them. Once you stage the file (with git stage as outlined above) you have to use a different command to "un-stage" it: git reset [path-to-file]. If you have staged many things and just want to un-stage all of them, you can type git reset with no path.
Once you have committed things that were not good, you have some options, but for now, use git revert [commit hash]. This will create a new commit that "undoes" the commit hash you provide.
Closing
Now that we have reviewed the basic workflow with Git, start using it! Spend some time playing around with the tool and using it to manage a project you are working on. The next steps will be learning what branches are and how to collaborate with other people. We will also need to dive deeper in to the internals off how Git works to help make it easier to reason through the more advanced commands.