Committing file changes

What are commits?

Git's main power comes from the ability to keep a record of every single change made to the files in your project by taking snapshots called commits.

When you commit, Git only stores a summary of the changes, rather than storing entire copies of every changed file. This keeps things fast and stops a repository from getting unreasonably large.

Adding changes to the staging area

Before you commit, you need to make some changes in your project.

You can run the git status command at any time for a list of files that have been added, changed, or removed inside your working directory.

The output will look a little something like this:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    index.html

nothing added to commit but untracked files present (use "git add" to track)

Every change you make isn't automatically included when you commit. You'll manually need to tell Git which changes you want to be included by adding them to the staging area using the git add command.

For example, let's say you've made changes to index.html. To add all the changes in this file, you can simply type git add index.html.

If you run git status again, you'll see that the output has changed slightly:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   index.html

Don't worry, you don't need to add every file one-by-one!

You can enter the name of an entire folder, or you just can use git add -A to add all of the changed files to the staging area at once.

If you change your mind, Git allows you to undo this operation.

Creating your first commit

Once you've added all the files you want to include in the commit, you'll need to run the following command:

git commit -m "message"

Replace message with a brief summary of the changes that you've made. Once you press enter the commit will be created.

[master (root-commit) d240853] Create the home page
 1 file changed, 107 insertions(+)
 create mode 100644 index.html

If you wish to have a more graphical interface with which to work, you can use Tower, where your commits and commit history are easy to understand and visualize!

Writing multi-line commit messages

The -m flag is convenient for short messages, but sometimes you need a subject line and a longer body. You can pass -m twice to achieve this:

$ git commit -m "Add login endpoint" -m "Validates credentials against the users table and returns a JWT."

The first -m becomes the subject line and the second becomes the body, separated by a blank line. Alternatively, running git commit without any flags opens your configured text editor so you can write a detailed message with as many lines as you need.

Reviewing changes before committing

The -v (verbose) flag appends a full diff of your staged changes beneath the commit message template in your editor. This lets you review exactly what you're about to commit while writing the message:

$ git commit -v

The diff is only shown for reference -- it won't be included in the actual commit message.

Amending the last commit

If you made a typo in your last commit message, or forgot to stage a file, the --amend flag lets you rewrite the most recent commit:

$ git commit --amend

This opens your editor with the previous commit message so you can correct it. If you've staged additional changes with git add, they'll be folded into the amended commit as well.

To update the staged files without changing the message at all, use:

$ git commit --amend --no-edit

Note: Amending rewrites history. Avoid amending commits that have already been pushed to a shared branch, as this will cause problems for anyone who has already pulled the original commit.

Creating an empty commit

The --allow-empty flag creates a commit with no file changes. This is useful for triggering a CI/CD pipeline or marking a specific point in history:

$ git commit --allow-empty -m "Trigger deployment"

Next steps

After committing, you can use git log to verify your commit appears in the history, then git push to share it with your team.

Once your code is committed and ready, DeployHQ can deploy it to your servers automatically from any Git repository.