When I first started learning git, I honestly felt like I was learning basic commands with little reason. I was learning what to do without learning why I was doing it and or what was actually happening in the grand scheme of things. Yes, I was saving data and changes to my local code so that others could see my revisions and work on the same files at the same time. But what was really happening and why was it happening? It felt as if I was learning how to perform calculus without understanding why I was doing the calculations. I was mindlessly repeating the same actions without realizing what was happening or why I was doing it hoping that everything would work out well for me. Most of the times I was lucky, and I was able to contribute to teams and code without a hitch. Other times, not so much.
So with this article, I wanted to give you the information that helped me understand what git is, what it can do, and the commands that I find to be the most helpful when working in a git repository. Keep in mind this article is meant to be very brief. It is not my intention to go very deep into the world of git.
So what is git?
Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development and was initially created by Linus Torvalds for development of the Linux Kernel.
Git is not Github. Git is the version control software, and Github is a git repository hosting service which offers all the source code management provided in git. Github is where you upload your git repository.
So what are some of the characteristics of git?
- Strong support for non-linear development:
Non-linear development allows yourself to work on different parts of a system concurrently. Thus you don’t have to build an app in a specific order. Maybe you are working on the UI of your system when you remember a bug in the back-end. You can save what you are currently working on, fix the bug, and return to your previous work with little hassle.
2. Distributed development:
Distributed development allows for multiple people to be working on the same project at the same time. Without version control you would not be able to work on the same file as someone else as one of your changes would overwrite the other’s code when committing.
Everything saved in git is accessible at some later point. Even if you delete it!! There is always a record of your save history. Thus it is tough to corrupt your code whether it occurs accidentally or maliciously.
Now lets dive a little deeper into the git workflow.
There are three core areas to git. These are the Working Tree, the Staging Area (also known as Index), and the Local Repository. When working in a git repository files and modifications will travel from the Working Tree to the Staging Area and finish at the Local Repository. Thus we will talk about these three areas in that order.
The Working Tree
The Working Tree is the area where you are currently working. It is where your files live. This area is also known as the “untracked” area of git. Any changes to files will be marked and seen in the Working Tree. Here if you make changes and do not explicitly save them to git, you will lose the changes made to your files. This loss of changes occurs because git is not aware of the files or changes in the Working Tree until you tell it to pay attention to them. If you make changes to files in your working tree git will recognize that they are modified, but until you tell git “Hey pay attention to these files,” it won’t save anything that goes on in them.
How can you see what is in your Working Tree? Run the command
git status. This command will show you two things: The files in your Working Tree and the files in your Staging Area. It will look something like the image below if you don’t have anything in your Staging Area.
The Staging Area (Index):
The Staging Area is when git starts tracking and saving changes that occur in files. These saved changes reflect in the .git directory. That is about it when it comes to the Staging Area. You tell git that I want to track these specific files, then git says okay and moves them from you Working Tree to the Staging Area and says “Cool, I know about this file in its entirety.” However, if you make any more additional changes after adding a file to the Staging Area, git will not know about those specific changes until you tell it to see them. You explicitly have to tell git to notice the edits in your files.
How can you see what is in your Staging Area? Run the command
git status like before. It will look something like the image below.
How do you add files to your Staging Area? Running the command
git add #filename# will add a specific file to the Staging Area from your Working Tree. If you want to add everything from the Working Tree, then run the command
git add . The
. operator is a wildcard meaning all files.
The Local Repository:
The Local Repository is everything in your .git directory. Mainly what you will see in your Local Repository are all of your checkpoints or commits. It is the area that saves everything (so don’t delete it). That’s it.
How do you add items from your Staging Area to your Local Repository? The git command
git commit takes all changes in the Staging Area, wraps them together and puts them in your Local Repository. A commit is simply a checkpoint telling git to track all changes that have occurred up to this point using our last commit as a comparison. After committing, your Staging Area will be empty.
How can you see what is in your Local Repository? There are a few commands that you can do that show different things.
git ls-tree --full-tree -r HEAD
This command shows all files within your git repo that it’s tracking. I don’t use this one that much because I rarely need to see every file that is being tracked by git.
I use this command a lot more as it brings up a log of all previous checkpoints in my repository. If I want to see more information about a specific commit, then I run the command
git show #commit# to see what was changed at that specific checkpoint.
So what commands should you use frequently?
I recommend using
git status --long as it allows you to get a comprehensive list of what is in you Working Tree and Staging Area. It lets you to know what files have been added, modified, and which files git is tracking.
I also recommend using
git diff to show all changes to modified files. This command shows you the code differences between a file in the Staging Area and the edits made to that file that currently exist in the Working Tree. If you want to see just the changes of one file you can do
git diff #filename#.If you want to see the changes in the Staging Area then you can append the
--staged flag to your command (
git diff --staged ).
git status and
git diff should frequently be used as they give you information about your current working state and what git is aware of. They allow you to see what changes have occurred since your last checkpoint and are what I use most often to guide myself to atomic commits.
Here are a list of other commands that you will see often and their uses:
git init→ Create a new git repository
git add “newfile”→ Add a new file to your staging area
git commit→ Adds staged changes to your local repository
git push “remote” “ branch”→ Push local repository changes to your hosting service
git pull “remote” “ branch”→ pull code from your hosting service to your local directory
git branch→ See local branches
git branch “newName”→ Create new local branch
git checkout “branchName”→ Switch branches
git diff→ See the actual difference in code between your working tree and your staging area
git status→ Show which files are being tracked v. untracked
git log→ Show recent commit history
git show“commit_id” → show details of specific commit
git stash→ stash working directory
git help→ manpages for git
git help “gitCommand”→ man pages for specific git command
If you have any questions or comments feel free to post them as I always love talking about git and learning more about git. Also feel free to call me out on any mistakes that I may have made as I would love to fix my working knowledge and hopefully not preach wrong information. I hope this information has helped you to better understand what is actually going on behind the scenes of git and has allowed you to expand your working knowledge of git. Cheers!