Glossary

Git commit

A commit stores a selected change in local history. It does not automatically mean a push, pull request, or deployment.

Short definition

A small, named step in a project’s history.

Git stores a commit as an object with a selected file state and a relationship to history. A commit is made from the staging area, not from every unfinished edit in the working copy. This lets you prepare two independent changes and commit them separately.

A commit first exists only in the local repository. Saving a file in an editor changes the working copy. Push sends a branch to a remote. A pull request is a proposal to integrate a change in a hosting service, not a built-in Git object.

What it is for

Readable history, review, and returning to a change

A good commit has one clear purpose. That makes the step easier to understand, test, review, or return when necessary.

saving one independent bug fix or a small part of a feature to local history
a sensible division of work for code review and future change tracing
running tests and CI against a specific change
comparing the state before and after one change or preparing a focused revert commit
recording the reason for a change in a commit message when the diff alone is not enough

Practical example

Fixing shipping calculation without unrelated changes

When fixing a shipping calculation, leave formatting in other files and unfinished administration work out of the commit. Put only the calculator change and the test that describes the fixed scenario into the staging area.

After the commit, the fix is recorded in local history. Only push makes it available on a remote, where a pull request can be opened. If someone has already fetched the commit, do not rewrite its history with amend or rebase without agreement; changed content receives a different hash.

Shell

git status
git add src/Shipping/ShippingPriceCalculator.php tests/Shipping/ShippingPriceCalculatorTest.php
git commit -m "Fix free-shipping threshold"
git push -u origin feature/shipping-threshold

How a change travels

A commit is only one part of the path to integration

Sequence: working files → staging area → local commit → branch on remote → pull request → review and CI → merge into main.

Save a file The editor writes an edit into the working tree. Git has not put it in the staging area or history yet.
Select content git add places selected lines or files into the staging area for the next commit.
Create a commit git commit stores a local record with selected content, a message, and parent history.
Share a branch git push sends the branch reference and missing objects to a remote repository. By itself, it neither opens a pull request nor deploys an application.
Integrate the change In a pull request, the team performs review and checks. Merge then joins the approved branch to the target branch according to project rules.

What is what

Commit, save, push, branch, and pull request are different things

This distinction makes it clear where a change is and who can see it.

Saving in an editor

Writes the current file content to the working copy. It does not select content for Git or create history.

Commit

Stores a selected snapshot locally. A commit has a hash derived, among other things, from its content and parents, so it is not only a permanent sequence number.

Push

Sends a local branch to a remote repository. It may trigger hosting-service automation, but Git push itself is not a merge or production deployment.

Branch and pull request

A branch is a movable reference to a commit. A pull request is a process around a remote repository that asks to join a branch, review it, and often run CI checks.

Amend and rebase

git commit --amend creates a replacement for the last commit. Rebase replays commits on another base. In both cases, rewritten commits receive new hashes, so change shared history only by agreement.

Benefits and risks

Readable history costs less than complicated repairs later

Benefits

an unambiguous purpose for the author and reviewer
easier problem tracing and focused reversal of a change
the ability to verify a small step with tests and automated checks
separation of unfinished work from a completed part of a change

What to watch

a large commit mixing a feature, a fix, and formatting
amend or rebase of already shared history without agreement
assuming a local commit is a backup outside your own computer
a secret added to a commit even if it is removed from the file later

Practical use

Commit when the change belongs together.

A commit does not need to contain an entire large feature. It should contain a step with a clear meaning that can be explained. During longer work, several small commits are better than one huge one when each preserves a sensible and verifiable state.

Do not commit access tokens, passwords, or private keys. If a secret enters a commit, revoke or rotate it as soon as possible. Rewriting history can limit further spread, but it does not retrieve the value from other clones, caches, or logs.

Checklist

What to check before committing

The goal is not to meet a formal number of commits. It is to leave a history that can be used safely.

git diff and git diff --staged show exactly the intended content
the message briefly describes the purpose of the change, not only a filename
relevant tests and static checks run against the change
the commit contains no secrets, local configuration, or accidentally added files
history rewriting affects only your unpublished work or has been agreed with the team

Common questions

Commit without common misconceptions

Is a commit the same as saving a file?

No. Saving changes the working copy. A commit stores in Git history only content that you selected in the staging area first.

Can others see a commit immediately?

Not necessarily. A commit is local first. Others normally see it after push to a shared remote repository or another history transfer.

Why does the hash change after amend or rebase?

A commit hash depends on its content and place in history, including parents. Amend creates a new commit and rebase replays commits on another base, so original identifiers no longer apply.

Is deleting a secret in the next commit enough?

No. An earlier commit can still contain it and it may already have been fetched. First revoke or rotate the credential, then deal with history and repository access as appropriate.

How I work with changes in practice

Code history should be readable even when something goes wrong.

My core skills describe work with PHP applications, testing, and sustainable architecture that all build on high-quality change management.

View core skills Discuss a project