Getting Started With Git
This is my guide on getting started with Git.
Getting Started With Git
Git is a way of doing version control. It is a way of keeping track of changes to files. You want to do this so you can look at previous versions and see what has changed. It is also a good way to work collaboratively. Git is a distributed version control system. This means that everyone who has cloned a repository has a full copy of the history.
Git thinks of your data as a snapshot. When you save the state of your project, it is called making a commit. I will get into this more later. Every commit is therefore a snapshot.
Git operates locally on your computer. Your local files are referenced and that link is saved on your computer. Git does not need to reach out to other computers or over a network in order to work. This makes it fast.
This also makes it easy to do your work. If you have to edit a file, you can do so and make your commit. Afterwards, when you find an internet connection, you can continue the process of uploading to a repository.
Almost everything you do in Git adds to the local database. That includes modifying files and committing files. You can lose work that you have not committed, so make sure and commit often.
File States
In Git, there are three states to your files. These states are modified, staged, and committed. Modified means a file has been changed but it has not been marked for staging and it has not been sent to the local database yet. Staged means your file has been marked to send to the database the next time you make a commit. Committed means your file has been sent to the database and a record of its changes are in the database.
File Workflow
This leads to the next major concept in working with Git. It is the workflow. Understanding these concepts will make things easier later on. Your workflow will be the working directory, staging area, and the ‘.git directory’. The working directory is the current version of the project you are working on. When you decide to work on a certain version of a project, files are taken from the database and placed on your drive in order for you to modify.
The staging area is technically a file in your Git directory. It contains the information on what will go into your next commit. It is also called the index because of what it keeps track of.
The Git directory is where all of the information and the database are stored. This is the part that is copied when you clone a repository.
Git Configuration
If you do not know whether you have Git installed or what version you have, you can just ask it in your terminal.
Git –version
Once you have Git installed, it is time to do a one time setup. This is done through the command:
Git config
This version with no parameters just shows you the options if you ever need them later. There are, however, a few specific actions you will need to do first to make Git work properly. We are going to set some details for your environment. The first is:
git config --global user.name "Jason Moore"
Just put your name in quotes there instead of mine.
Now we want to set your email variable. Do this like:
git config --global user.email [email protected]
Just put your email in there that you want to use.
You can also set your default text editor. A text editor is something like Vim, Emacs, or Nano. You will know if you use one. They are the quickest and easiest way to work with text files. You set your default like this:
Git config –global core.editor vim
You can check your settings at any time. You can do so like this:
Git config –list
This shows you everything you have setup and some extra the system did.
You can change anything you did by just entering the command in again, such as the email.
Using Help
The help system is very useful. It is well maintained so make sure and use it.
Git help [command]
Or:
Git [command] help
Starting a Repository
The first step most people do is take a directory they are working in and make it a repository. Doing this means Git will start tracking everything that happens in that directory. I am assuming you are on the command line and know how to change directories to make that directory your current and active directory that will now be tracked by Git.
For me it looks like this:
Cd /home/jason/writing
Once you are in the directory that you want Git to track you type:
Git init
This will create a new subdirectory in your project folder that contains all the necessary repository files. Nothing will be tracked, though, until you start adding files and commit them. Remember the workflow from earlier? You have to modify a file, stage it, and then commit it to the local database.
The first step is adding files.
You can add all files in your project directory at once to be staged by:
Git add .
The period at the end means to add everything in your current directory.
You can add all of a certain type of file.
Git add *.py
Or
git add *.cpp
You can add any individual file:
Git add algebra_examples
Everything you decide to add to staging is ready to be committed to the database. Do so like this:
Git commit -m ‘first files to track’
You will see an output message, this is good.
Working In Your Repository
Now you work on your files. Your system is set up and ready to track changes. So, write the next chapter in your novel or write some code. When you do a little bit of work, you should add it to staging, then commit it to your local database so it does not get lost. This is like saving a document in a program. If you have done enough to save, then you have done enough to make another commit. The principle is the same.
The next thing you want to do is check the status of your files and tracked directory. You do this with the ‘status’ command.
Git status
If there is a file that Git says is untracked, that means it has not been added to the local database. You can always add it later.
Git add geometry
The next time you run the status command you will not see that file labeled as untracked.
You can also track directories. If you do this, everything in that directory is automatically tracked by Git. I would do this by using this command:
Git add writing
That will get all the files in the writing directory and start tracking them.
Ignoring Files
After you have been working on your files a while, you will eventually find that you do not want some files tracked. An example of this would be a ‘.log’ file that you will never directly work in. To do this, you can make a file called:
.gitignore
Inside, you can add things like this for Git to ignore these types of files:
*.log
*.o
You should get the idea. When you need this, I hope you will remember to come back here and look. It is a good idea to set this up in your project directory at the beginning so you will remember it is an option later on.
Viewing Your Changed Files
Sometimes we need to know what has changed in a file, not just the name of the file. There is a good command for this and it is:
Git diff
This command shows the difference in files, what you have changed but not staged, and what you have staged. It shows you the exact lines that were added and removed but have not been staged.
Committing Your File Changes
Once everything has been staged that you want, it is time to commit your file changes. The only files that will be committed to your local database are the ones you have run ‘git add’ on. You can run:
Git commit
However, this method is a bit clunkier as it will open your default editor and you will have to edit it to actually make the commit. Some prefer this method and that is just fine. I think it is easier when starting out to just use
Git commit -m ‘your commit message here’
This does the same thing. I think it is better for those new to Git.
A commit only records changes that were staged with the ‘git add’ command.
You can even skip the staging area if you want to. You can do this with the ‘-a’ flag.
This will commit file changes that were not staged with the ‘git add’ command. An example looks like this:
Git commit -a -m ‘Added a chapter to statistics study guide’
Now you get the same effect.
Untracking Files
Sometimes, you will want to stop tracking a particular file or directory. To do this, you remove the file from tracking. If I want to stop tracking my geometry file, I do this:
Rm geometry
This is almost like modifying the file.
Git rm geometry
This command stages it for the next commit.
Git -m “this day’s commit”
The geometry file will be gone and untracked on your next commit, whatever it is.
Moving Files
You can easily move files within the Git system and it still keeps track of them. Git considers a file renamed when it has been moved. Remember that distinction.
So:
Git mv proofs proofs_changed
Git status
You will see that Git considers the file renamed.
Seeing Commit History
Seeing your commit history can be very useful. For example, if you have cloned someone else’s repository, then you will want to read the commit history of the project to see what has happened in it. To do this, we are going to use the command:
Git log
Git will show you the commit history of the project you are in. The most recent commits are shown first. To get more detail:
Git log -p
This shows you the patch difference between commits.
If you just want to see the last 3 commits then do this:
Git log -p -3
This shows you the last 3 commits and the patch history.
Another useful flag is ‘stat’
Git log –stat
You can also make it look nicer with the ‘pretty’ flag
Git log –pretty-oneline
Another interesting flag is:
Git log –graph
This will give you a little visual information.
We can limit the log output easily. It looks like this:
Git log –since=4.weeks
There are a lot more options to do with this.
Safety Features
We all make mistakes. When we do, it is nice to be able to get out of it without doing further damage. That is why Git has this section.
When we leave something out of a commit, we use the ‘amend’ option.
Git commit –amend
To unstage a file we use:
Git reset HEAD statistics
Then run:
Git status
We can also use ‘git restore’ which is newer. This gives us another way to unstage a file.
Git restore –staged statistics
Then run git status again to see the changes that Git sees