Introduction
In this lab, you will learn the fundamental commands for managing a local Git repository in a Linux environment. You will start by initializing a new repository using git init and configuring your user identity with git config, which are the essential first steps for any project using Git for version control.
Following the initial setup, you will practice the core Git workflow. This includes creating a new file, staging it for tracking with git add, and saving it to the repository's history with git commit. You will then modify the file, commit the changes, and learn how to review the complete commit history using the git log command to understand the project's evolution.
Initialize a Git Repository and Configure User Settings
In this step, you will begin by initializing a new Git repository and configuring your user information. A Git repository is a directory where Git tracks changes to your project files. Initializing a repository is the first step in using Git for version control.
Your current working directory is /home/labex/project. We will use this directory to create our Git repository.
First, run the git init command. This command creates a new, empty Git repository in the current directory. It does this by creating a hidden subdirectory named .git that contains all the necessary repository files.
git init
You should see output confirming that an empty repository has been initialized:
Initialized empty Git repository in /home/labex/project/.git/
Now that the repository is created, the next step is to set up your user identity. Git uses this information to associate your name and email address with every commit you make. This is crucial for tracking who made which changes in a collaborative project.
We will use the git config command with the --global flag. The --global flag ensures that this configuration applies to all Git repositories you work with on this system for the labex user.
Execute the following commands to set your username and email address. For this lab, we will use labex as the username and labex@example.com as the email.
git config --global user.name "labex"
git config --global user.email "labex@example.com"
These commands do not produce any output if they are successful. To verify that the configuration has been set correctly, you can list all the Git configuration settings for your user:
git config --list
The output will show a list of all settings, including the user.name and user.email you just configured:
user.name=labex
user.email=labex@example.com
...
You have now successfully initialized a Git repository and configured your user identity. You are ready to start adding files and tracking changes.
Create and Commit the First File with git add and git commit
In this step, you will create your first file and commit it to the Git repository. Committing is the process of saving a snapshot of your staged changes to the repository's history. This process involves two main commands: git add and git commit.
First, let's create a simple README.md file. This is a common file in projects that provides information about the project. We'll use the echo command to create the file and add some text to it. All commands should be run in your current directory, /home/labex/project.
echo "Hello, Git" > README.md
Now that you've created a file, you can check the status of your repository using the git status command. This command shows you the state of the working directory and the staging area.
git status
The output will look like this:
On branch master
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)
This output tells you that README.md is an "untracked file." This means Git sees the file, but it's not yet part of the repository's version history.
To start tracking the new file, you need to add it to the staging area. The staging area is an intermediate step where you can prepare a set of changes before committing them. Use the git add command to stage README.md.
git add README.md
This command doesn't produce any output. To see what happened, run git status again.
git status
Now the output has changed:
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md
The file is now listed under "Changes to be committed," which means it's in the staging area and ready for the next commit.
Finally, to save this snapshot to your project's history, use the git commit command. It's a best practice to include a descriptive message with each commit using the -m flag. This message explains what changes were made.
git commit -m "Initial commit: Added README.md"
After running the command, you will see a confirmation message summarizing the commit:
[master (root-commit) <commit_hash>] Initial commit: Added README.md
1 file changed, 1 insertion(+)
create mode 100644 README.md
You have successfully made your first commit! The README.md file is now officially part of your Git repository's history.
Modify a File and Commit the Changes
In this step, you will learn how to track modifications to an existing file. A key feature of version control is the ability to see how files evolve over time. This is done by committing changes each time a file is updated.
We will continue working with the README.md file in the /home/labex/project directory. Let's add a new line of text to it. We'll use the echo command again, but this time with the >> operator, which appends content to a file instead of overwriting it.
echo "This is a new line." >> README.md
Now that the file is modified, let's check the repository's status with git status.
git status
Git will report that the README.md file has been modified:
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
The output shows modified: README.md under "Changes not staged for commit." This means Git has detected the change, but it has not yet been added to the staging area for the next commit.
Just like with a new file, you must use git add to stage the modifications. This tells Git that you want to include these specific changes in your next commit.
git add README.md
Again, this command produces no output. Let's run git status one more time to confirm the change has been staged.
git status
The output now shows the file under "Changes to be committed":
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
Now that the changes are staged, you can commit them to the repository's history. Use git commit with a clear message describing the update.
git commit -m "Added a new line to README.md"
You will see a confirmation message for the commit:
[master <commit_hash>] Added a new line to README.md
1 file changed, 1 insertion(+)
You have now successfully modified a file and committed the changes. This workflow—modify, stage, and commit—is the fundamental cycle you'll use repeatedly when working with Git.
Review the Commit History with git log
In this final step, you will learn how to review the commit history of your repository. The git log command is a powerful tool that allows you to see a chronological list of all the commits that have been made. This is essential for understanding how a project has evolved.
From your /home/labex/project directory, run the git log command:
git log
This command will display a detailed list of the commits you've made, with the most recent commit appearing first. The output will look similar to this:
commit <commit_hash_2> (HEAD -> master)
Author: labex <labex@example.com>
Date: <commit_date_2>
Added a new line to README.md
commit <commit_hash_1>
Author: labex <labex@example.com>
Date: <commit_date_1>
Initial commit: Added README.md
Let's break down the information for each commit:
commit: A unique 40-character SHA-1 hash that serves as the identifier for the commit.Author: The name and email of the person who made the commit, based on your Git configuration.Date: The timestamp indicating when the commit was made.- Commit Message: The indented text is the message you provided with the
-mflag, explaining the purpose of the commit.
The log is displayed in a pager program (like less). You can scroll up and down using the arrow keys. To exit the log view and return to your terminal prompt, simply press the q key.
For a more compact view of the commit history, you can use the --oneline flag. This is useful for getting a quick overview.
git log --oneline
The output will be much shorter, showing just the commit hash and the commit message on a single line for each commit:
<short_hash_2> (HEAD -> master) Added a new line to README.md
<short_hash_1> Initial commit: Added README.md
Congratulations! You have now learned the basic workflow of initializing a Git repository, adding and committing files, and reviewing the project's history.
Summary
In this lab, you learned the fundamental steps to manage a local Git repository in a Linux environment. You began by initializing a new repository in a project directory using the git init command. Following the initialization, you configured essential user settings, specifically your username and email, with the git config --global command to ensure all future commits are properly attributed. The core workflow of version control was then practiced by creating a new file, staging it for the next commit with git add, and then permanently recording the changes in the repository's history using git commit.
Furthermore, you practiced the iterative process of making and tracking changes. This involved modifying an existing file and then repeating the staging and committing cycle with git add and git commit to save the new version. Finally, you learned how to review the project's history by using the git log command, which displays a chronological list of all commits, including their unique identifiers, authors, dates, and commit messages. This provided a clear overview of the changes made to the repository over time.
