Adding and Committing Changes

Now we can create our first real Git commit. To keep the example simple, imagine we already have a Git repository called git-demo, and inside it we create a new file:

hello.txt

The file can contain something simple:

Hello Git

After creating the file, run:

git status

Because the file is new, Git will usually show it as an untracked file. This means Git can see the file, but it is not yet part of the repository's tracked history.

You may see something like:

Untracked files:
  hello.txt

If we want this file to be included in our next commit, we first stage it:

git add hello.txt

Remember that git add does not create a commit. It only places the selected change in the staging area.

Run git status again:

git status

Now Git may show:

Changes to be committed:
  new file: hello.txt

This tells us that hello.txt is ready to be included in the next commit.

Adding Multiple Files

You can stage several files at the same time:

git add index.html style.css app.js

If you want to stage all current changes in the current directory, you can use:

git add .

The . means the current directory.

This command is very common because it is convenient, but it is still a good idea to run git status first. Otherwise, you may accidentally stage files you did not mean to commit.

For example, a project might contain files such as:

debug.log
password.txt
temporary-file.txt

Some of these may not belong in Git at all. So while git add . is useful, you should still know what you are adding.

Creating a Commit

Once your changes are staged, you can create a commit with:

git commit -m "Add hello file"

The -m option lets you provide the commit message directly in the command.

If the commit succeeds, Git may print something like:

1 file changed, 1 insertion(+)
create mode 100644 hello.txt

At this point, the change has been recorded in your local Git history.

A commit message should briefly explain what the change does. Good examples include:

Add login page
Fix login error
Update README
Remove unused code

Messages such as these are less useful:

update
change
test
aaa

They may seem fine at the moment, but they are difficult to understand when you look back at the history weeks or months later.

Making Another Commit

Now suppose you update hello.txt:

Hello Git
Git is easy to learn.

If you run:

git status

Git will show that the file has been modified, but the new change is not staged yet.

Stage it again:

git add hello.txt

Then create another commit:

git commit -m "Update hello message"

Your history now contains two separate commits:

Add hello file
Update hello message

This is an important idea: a commit is not simply a one-time save of the whole project. Git builds a history through many small commits over time.

A Common Everyday Workflow

A basic development workflow often looks like this:

git status

Check what changed, then stage the changes:

git add .

Check again:

git status

And finally commit:

git commit -m "Describe your change"

You can think of the workflow as:

Running git status several times may feel repetitive at first, but it is one of the easiest ways to understand what Git is doing.

Create the first commit for hello.txt without staging password.txt.

A Commit Is Still Local

There is one important distinction to understand early: git commit saves the commit in your local repository. It does not automatically upload anything to GitHub.

In other words:

Uploading commits to GitHub is done with:

git push

The remote-repository material later in the course explains git push in detail.