Git Fundamentals

init, clone, add, commit, status, log

These core commands form the backbone of Git, facilitating the initialization of repositories and the tracking of incremental changes over time. Mastering these operations is essential for maintaining a clear project history, enabling effective version control, and collaborating with others through distributed workflows. You will reach for these fundamental tools daily to start new projects, inspect repository states, and permanently record your development milestones.

Initializing a Repository with git init

The git init command serves as the genesis point for any version-controlled project. When you execute this in a directory, Git creates a hidden subdirectory called .git, which acts as the brain and database for the repository. This directory is where Git stores all metadata, object database references, and configuration files. By initializing a directory, you tell Git to begin monitoring the filesystem for changes. It is crucial to understand that this does not automatically add existing files to version control; it merely prepares the directory to accept them. Think of it as installing a specialized filing system that tracks every nuance of your work. Without this directory, Git is unaware of your files' history. Once initialized, the repository enters a state where it can begin mapping the relationship between files and their evolution, setting the stage for future snapshots to be captured systematically.

# Create a new directory and navigate into it
mkdir web-project && cd web-project

# Initialize the folder, creating the hidden .git metadata repository
git init  # Output: Initialized empty Git repository in .../.git/

Capturing Projects with git clone

While git init starts a project from scratch, git clone is the gateway for working on existing distributed projects. When you run this command, Git performs a full copy of the remote repository, including its entire history, every branch, and every tag. This is different from a simple file download because it downloads the repository's brain, allowing you to operate entirely offline or locally after the initial sync. Cloning effectively sets up a local repository that is pre-configured to communicate with the remote source. It automatically establishes a 'remote' reference usually named 'origin'. By capturing the full repository history, Git ensures that every contributor possesses a complete, redundant backup of the project's evolution. This distributed nature is why Git is so robust; if a central server fails, the entire project timeline is safely replicated across all developer machines, ready to be reconstructed at any given moment.

# Clone an existing project from a remote host to your local machine
git clone https://github.com/organization/web-project.git

# Navigate into the freshly cloned repository folder
cd web-project

Monitoring Changes with git status

The git status command is your primary feedback mechanism, providing a real-time report on the relationship between your working directory and the current commit. It identifies files that have been modified, created, or deleted but not yet recorded in the project's history. Git categorizes changes into three zones: untracked files (new items not yet in the repository), modified files (existing items with recent changes), and the 'staged' area. Understanding this command is vital because it reveals the state of your 'staging area,' which acts as a staging ground for the next commit. If you perform work and forget to check status, you risk committing incomplete or unwanted changes. Think of it as a pre-flight checklist. By reading the status output, you learn exactly which files are prepared to be saved and which remain ignored or untracked, ensuring you always maintain complete control over the snapshot about to be generated.

# Check the state of your working directory
git status

# Observe untracked files or modified files waiting to be staged
# This tells you what will be included in the next commit

Preparing Snapshots with git add

Git operates on the principle of a staging area, or 'index.' Simply modifying a file in your editor does not automatically tell Git to include those changes in a snapshot. You must explicitly move those changes into the staging area using git add. This design allows you to selectively choose which file modifications belong together in a single logical commit. For example, you might fix a bug in one file and refactor code in another; by adding them separately, you can construct clean, focused commits. Staging is essentially the process of creating a preview of the next commit. When you add a file, Git calculates a cryptographic hash for that version of the file and stores it in the database. This allows for incredibly granular control over your version history, ensuring that the final commit reflects only the changes that are truly ready to be shared or saved.

# Add a specific file to the staging area
git add style.css

# Add all current changes in the directory to the staging area
git add .  # The '.' represents the current directory

Committing and Inspecting with commit and log

Once changes are staged, git commit freezes them into a permanent record in the project history. A commit is not just a file save; it is a snapshot of the entire project state, captured with a unique identifier and a descriptive message. The commit history can be viewed using git log, which displays a chronological list of these snapshots, including the author, timestamp, and the unique hash that identifies the state. These logs serve as an audit trail for every feature added or bug fixed. By keeping commit messages clear, you create a readable narrative of why changes occurred, rather than just what changed. The git log command is powerful because it allows you to traverse time, helping you understand how the project evolved over weeks or months. Mastering these commands allows you to confidently manage complex development cycles while keeping a pristine historical record of every single advancement.

# Permanently record the staged changes with a descriptive message
git commit -m "Fix navigation styling in the header"

# View the historical record of snapshots to trace project evolution
git log --oneline  # Displays a compact, one-line summary of each commit

Key points

A repository initialized with git init contains a hidden .git folder that stores all project metadata and history.
The git clone command replicates an entire project repository, including all historical commits, onto a local machine.
Git uses a staging area, or index, which acts as a middle ground between your working files and a permanent commit.
The git add command moves modifications into the staging area, allowing for precise control over what is included in a snapshot.
The git status command provides essential feedback regarding which files have been modified or are currently untracked.
Committing changes via git commit transforms the staging area into a permanent, immutable snapshot in the repository history.
Every commit requires a message to explain the rationale behind changes, which is vital for long-term project maintenance.
The git log command enables developers to audit the history of a project by displaying all past commits in chronological order.

Common mistakes

Mistake: Forgetting to run 'git add' after modifying a file. Why it's wrong: Changes in the working directory are not automatically tracked or included in the next commit. Fix: Run 'git add <filename>' before committing to stage the changes.
Mistake: Committing too many unrelated changes at once. Why it's wrong: It makes the history difficult to navigate and makes reverting specific features impossible. Fix: Use 'git add' selectively to create logical, atomic commits.
Mistake: Running 'git init' inside an existing Git repository. Why it's wrong: It can cause configuration conflicts and corrupt the local repository metadata. Fix: Check for a '.git' folder in the directory before running 'git init'.
Mistake: Confusing 'git status' with 'git log'. Why it's wrong: Status shows the current state of the working directory and staging area, while log shows historical commit data. Fix: Use status to see what needs to be added, and log to review past changes.
Mistake: Assuming 'git clone' updates the remote repository. Why it's wrong: 'git clone' creates a local copy, but does not push local changes to the remote. Fix: Use 'git push' to send local commits to the server.

Interview questions

What is the purpose of 'git init' and when do you typically use it?

The 'git init' command is the foundation of working with version control, as it initializes a new, empty Git repository in your current working directory. You use it when you want to start tracking an existing project or create a brand new one from scratch. By running it, Git creates a hidden '.git' subdirectory that stores all the metadata and object database for your project history. This is essential because, without this initialization, Git cannot track changes, manage branches, or interact with remote repositories, effectively leaving your project as a standard folder without versioning capabilities.

How does 'git clone' differ from 'git init'?

The primary difference lies in the source of your project. While 'git init' creates a local repository from scratch, 'git clone' is used to download an existing remote repository from a service like GitHub to your local machine. When you run 'git clone', Git automatically creates a directory, initializes a new repository, downloads all the project history, and sets up a remote tracking branch. It is the most common way to start contributing to an existing team project, as it ensures you have the complete history, branches, and tags immediately available for your local development work.

What is the role of 'git status' and why is it considered the most important command for daily workflow?

The 'git status' command acts as a diagnostic tool that provides a snapshot of the current state of your working directory and the staging area. It is vital because it tells you exactly what files have been modified, which ones are ready to be committed, and which files are currently untracked by Git. By running this command frequently, you avoid accidentally committing unwanted files or missing critical changes. It provides the visibility needed to manage your workflow safely, confirming your current branch and identifying the next necessary steps before you proceed to commit your hard work.

Explain the relationship between 'git add' and 'git commit' and why we need a staging area.

The relationship between these commands is centered on creating a clean, organized history. 'git add' is used to move files from your working directory into the staging area, which acts as a staging ground for the next commit. 'git commit' then takes everything currently in the staging area and records it as a permanent snapshot in the repository history. We need this two-step process because it allows developers to curate their commits, enabling them to group related changes together into a single, logical commit instead of dumping every single modification into the history at once.

What is the utility of 'git log' and what information can you derive from it?

The 'git log' command is your primary tool for inspecting the history of your project. It displays a chronological list of all commits, showing the unique commit hash, the author's name, the date of the change, and the descriptive commit message. This is essential for debugging, as it allows you to identify exactly when a regression or bug was introduced. By reviewing the logs, team members can understand the evolution of the codebase, verify who made specific changes, and reconstruct the reasoning behind complex features or fixes implemented in the past.

Compare the workflows of using 'git commit -a' versus staging files manually with 'git add'; when would you choose one over the other?

The main difference is control. Using 'git commit -a' automatically stages all tracked files that have been modified or deleted before committing them, which is a faster workflow for quick updates. However, manual staging with 'git add' is superior for larger projects because it allows for granular control; you can stage only specific chunks of a file or select individual files to be committed together. You should choose 'git add' when you want to group disparate changes into multiple logical commits, whereas 'git commit -a' is appropriate only when your working tree is clean and you want to record every pending change in a single, broad commit without needing granular separation.

All Git & GitHub interview questions →

Check yourself

1. A developer modifies three files, runs 'git add' on two of them, and then runs 'git commit'. What happens?

A.All three modified files are committed.
B.Only the two added files are committed.
C.The commit fails because the third file is unstaged.
D.None of the files are committed until 'git push' is called.

Show answer

B. Only the two added files are committed.
Git only commits files that are currently in the staging area. The third file remains modified but unstaged, so it is ignored. Option 0 is wrong because Git is explicit. Option 2 is wrong because an empty stage or partial stage is allowed. Option 3 is wrong because push is for remote synchronization, not local recording.

2. What is the primary function of 'git status' in a daily workflow?

A.To sync the local repository with the remote server.
B.To display the history of commits made by all team members.
C.To check which files are staged, unstaged, or untracked.
D.To finalize and save the current state of all files permanently.

Show answer

C. To check which files are staged, unstaged, or untracked.
Status shows the current workspace context. Option 0 is the job of fetch/pull. Option 1 is the job of log. Option 3 describes a commit, not a status check.

3. Why would you run 'git log' after a series of commits?

A.To verify that your changes were successfully recorded in the repository history.
B.To see if any files have been deleted from the working directory.
C.To automatically resolve conflicts between local and remote code.
D.To initialize a new repository inside a subfolder.

Show answer

A. To verify that your changes were successfully recorded in the repository history.
Log provides a chronological list of snapshots. Option 1 is tracked by status. Option 2 is a separate process. Option 3 describes git init.

4. What does 'git clone' perform under the hood?

A.It only copies the latest version of the files to your machine.
B.It downloads the entire repository history and sets up a local repository.
C.It merges the remote repository into your existing local project.
D.It adds the remote server as a local branch.

Show answer

B. It downloads the entire repository history and sets up a local repository.
Git is a distributed system, so cloning downloads the full history and metadata. Option 0 is incorrect because it copies the full history, not just the current files. Option 2 implies an existing repo, which clone doesn't expect. Option 3 is conceptually incorrect regarding how remotes work.

5. If you are in a directory and run 'git init', what is the immediate effect?

A.All files in the directory are automatically committed.
B.A hidden '.git' directory is created to manage repository metadata.
C.The directory is automatically uploaded to a remote hosting service.
D.The directory is locked until you provide a commit message.

Show answer

B. A hidden '.git' directory is created to manage repository metadata.
Init initializes the metadata structure. Option 0 is false as nothing is tracked yet. Option 2 is false as git init is purely local. Option 3 is false as Git does not lock directories.

Take the full Git & GitHub quiz →