This hands-on exercise guides you through creating your first Git repository, adding files, and committing them. You will learn the fundamental Git workflow.
First, you need a place for your project to live. Open your terminal or command prompt. Create a new directory for this practice session and navigate into it:
mkdir my-git-project
cd my-git-project
This directory, my-git-project, is currently just a regular folder. Git isn't tracking anything inside it yet.
Now, let's turn this directory into a Git repository. Use the git init command:
git init
You should see output similar to this:
Initialized empty Git repository in /path/to/your/my-git-project/.git/
This command creates a hidden subdirectory named .git. This .git directory contains all the necessary files and metadata for your repository, including the history, configuration, and object database. You typically won't need to interact with the .git directory directly.
Let's see what Git thinks about our new repository. Use the git status command:
git status
The output will look something like this:
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)
This tells us several things:
main branch (this might be master on older Git versions, but main is the modern default).Let's create our first project file. Use your preferred text editor or a command like echo to create a simple README.md file:
# Using echo (on Linux/macOS/Git Bash)
echo "# My Awesome Project" > README.md
# Or create the file manually with a text editor and add some text.
Now, run git status again:
git status
The output has changed:
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
nothing added to commit but untracked files present (use "git add" to track)
Git sees the new README.md file but tells us it's "untracked". This means the file exists in your working directory, but Git isn't tracking its history yet.
To start tracking the file and prepare it for the next commit, we need to add it to the staging area using git add:
git add README.md
This command tells Git, "I want to include the current state of README.md in the next snapshot (commit)."
Let's check the status one more time:
git status
The output now shows:
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md
README.md is now listed under "Changes to be committed". It has been moved from the working directory status (untracked) into the staging area.
Here's a simple visualization of the states you've just experienced:
Files move from the Working Directory to the Staging Area with
git add, and then are saved permanently into the Repository history withgit commit.
The file is staged and ready. Let's create the first snapshot of our project history using git commit. We'll use the -m flag to provide a descriptive commit message directly from the command line.
git commit -m "Initial commit: Add README.md"
You'll see output similar to this:
[main (root-commit) abc1234] Initial commit: Add README.md
1 file changed, 1 insertion(+)
create mode 100644 README.md
This confirms that the commit was created.
[main (root-commit) abc1234] indicates the branch (main), that it's the very first commit (root-commit), and the beginning of the unique commit hash (abc1234). Your hash will be different.README.md was created).Now, what does git status show?
git status
Output:
On branch main
nothing to commit, working tree clean
Everything is committed! Your working directory matches the latest snapshot stored in the repository, and the staging area is empty.
You can see the commit you just made using git log:
git log
The output will display details about your commit:
commit abc1234567890def1234567890abcdef12345678 (HEAD -> main)
Author: Your Name <[email protected]>
Date: Mon Oct 26 10:30:00 2023 -0700
Initial commit: Add README.md
This shows the full commit hash, the author and email (from your Git configuration), the date, and the commit message.
.gitignoreOften, projects generate temporary files, logs, or build artifacts that you don't want to include in your Git history. Let's simulate this.
Create a temporary file:
echo "Temporary scratch notes" > notes.tmp
Check the status:
git status
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.tmp
nothing added to commit but untracked files present (use "git add" to track)
Git sees notes.tmp as untracked. To tell Git to ignore this file and any other files ending in .tmp, create a file named .gitignore (note the leading dot):
echo "*.tmp" > .gitignore
This creates the .gitignore file and adds a pattern *.tmp to it. The asterisk * acts as a wildcard, matching any sequence of characters.
Now, check the status again:
git status
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
nothing added to commit but untracked files present (use "git add" to track)
Notice that notes.tmp is no longer listed! Git is now ignoring it based on the rule in .gitignore. However, the .gitignore file itself is new and untracked. Since configuration like ignore rules should be part of your project history (so others using the repository benefit from them), let's add and commit it:
git add .gitignore
git commit -m "Add .gitignore to exclude temporary files"
Check the status and log one last time:
git status
git log
git status should report nothing to commit, working tree clean. git log will now show two commits in your history.
Congratulations! You have successfully initialized a Git repository, added files to the staging area, created commits to save snapshots of your project, and configured Git to ignore specific files. You've practiced the core workflow you'll use frequently when working with Git.
Was this section helpful?
© 2026 ApX Machine LearningEngineered with