Hi everyone, today I’ll continue the series about Git Internal. Let’s dive into the Git commit flow and test the theory with hands-on experiments.
- When we work with source code, we are working in the working directory (which is the folder containing the .git folder).
- After we modify the code, we want to save those changes, and they will be stored in the Repository (image 1).
- However, the code doesn’t go straight from the Working Directory to the Repository; it has to go through an intermediary stage called the Index or Staging Area.
- Files in the working directory have two states: Tracked and Untracked. Tracked files are those that have been committed or are in the staging area, while Untracked files are the rest.
Enough theory, now let’s verify it with some hands-on testing.
- First, I’ll initialize a repository named repo_1 using the command "git init repo_1". To check the result of the above command, we can use the command "tree /f .git".
- The result shows the structure of the files in the .git folder. Let’s create any file in the folder, for example, using the command: echo hello > new_file.txt.
- Next, we’ll add and commit the newly created file, and then run the tree /f .git command again to see the changes.
- There are many changes now. Pay attention to the objects folder: hashes with the same first two characters are grouped into a folder with that name.
- Notice that the logs folder records the history of actions like commit, merge, rebase, reset, etc., while the refs folder contains branch and tag pointers, and the objects folder stores the objects.
Thank you for following along!
