In this second post of Git, I will post about the fundamental things about Git related with repository structure and file status life cycle, and its essential commands. If you have not read about my previous post about Git, you can see at Getting Started with Git.
I think it is vital knowing basic knowledge of something before we have decided to use in our development. So, let's start study from how Git manages its files and folders within the repository.
We created an empty folder and initialised a new repository using the
git init command like
cd sites/firstrepo in my first post. Once we have initialised
.git subfolder inside our folder, it become working directory. You can move the working directory around your file system without worrying any data loss of your repository.
Because of that
.git directory, we can track the file status, configure the repository, and so on. Let's continue looking how Git tracks the repository based on each file statuses.
When you create or copy a new file in the working directory, the state of the file is untracked at the first place. It means that Git knows that a new file is added but it won't take care and leave it untouched. You can add new files to the repository by
git add command. The state of the file become unmodified once it is added. It means that the file is new and ready to be committed to the repository or it has reached the staging area, also called index.
When you make any changes a committed file, which are already added to the index, the file status changes to modified from unmodified. The following illustration explains the file status life cycle.
taken from Git Essentials (2015) Ferdinando Santacroce
The staging area
The staging area, also called index, is a virtual place that collects all the files you want to include in the next commit. If you want a file to include in the next commit, you have to stage it using the
git add command. You can also unstage it to remove from the next commit if you want to delete or stage a file accidentally.
Unstaging a file
Unstaging a file can be done in many ways. However, it imposes problems when there are several ways to do the same things. Fortunately, Git often suggests the best way to do what you want to do and warns you when you use obsolete commands. You can always see some useful suggestions by typing
git <command> --help (-h for short) for seeing what your command is for and how to use it. This following procedure shows recommended commands in unstaging a file with better options.
- Open the repo folder that included the file you want to unstage. Based on the repo that created at my previous post, the command will be
cd sites/firstrepoin Terminal for Mac OS X.
- It is better your repo needs to be in clean state to clearly see the result. Type
git statusto check the repo state. If Git says nothing to commit, working directory clean, you can start unstaging.
- Create a new file by typing
git add NewFile.txtcommand for adding it to the index to enable Git tracking it.
- When done, type
git rm --cached <file>command to back the file in the untracked status. You can see in following screenshot showing how to unstage a file.
git reset HEAD <file>command can be used to unstage a file, I don't not recommend as it can completely destroy your actual work if used improperly.
git rmcommand, use with
--cachedoption if you want to remove the file only from the index not from the file system. If you use
git rmcommand on an already committed file, the file will be deleted from the index at the next commit but from local immediately.
Viewing the history
You can always see the history of your repository with
git log command. The
git log command is very useful and powerful. It will show the history of commits along with important details within the repository.
In this post, I only focus on the understanding of the git repository structure and its files statuses life cycle. Thank for your time for reading this post and see you in my next post about Git Initial Configuration and Work Remotely.