Glossary

Git

Git records changes, branches, and project history. It is not the same as GitHub or automatic deployment, nor does it replace thoughtful review and backups.

Short definition

A local history of changes that can be shared with others.

Git stores commits as a connected history of project contents. A developer works in the working tree, selects changes for the staging area, creates a commit, and sends it to a remote repository when needed. Branches allow changes to be developed separately and then deliberately integrated.

Because Git is distributed, a remote repository is not “Git itself” but one place for sharing history. GitHub, GitLab, or another service can provide pull requests, permissions, issue tracking, and CI around a repository, but these are not part of the basic Git model.

The problem it solves

Traceable changes and collaboration on the same code

Version control allows teams to understand a change, connect it to tests, and safely integrate it into shared history.

separate development of features and fixes in branches
finding the author, content, and context of a change in history
review and CI checks before merging into the main branch
tagging a specific version for a release or deployment
returning to an earlier code state with awareness of the impact on data and operations

Practical example

A branch for an inventory import

A developer creates a branch, prepares a small change, adds it to the staging area, and creates a commit. They then send the branch to a remote repository, where a pull request with review and checks can be opened.

These commands do not imply automatic deployment or task completion. Only the team’s rules, CI, review, and deployment process determine what actually happens after the change is merged into the main branch.

git switch -c feature/stock-import
git add src/Import/
git commit -m "Add idempotent stock import"
git push -u origin feature/stock-import

How it works

From a working copy to a shared change

Text diagram: working tree → staging area → local commit → remote repository.

Working tree A developer changes files in the project’s working copy.
Staging area The git add command selects which changes will be part of the next commit.
Commit Git stores a local history record with the selected content and parent commits.
Sharing a branch Push sends local references to a remote repository; by itself, it does not mean a production deployment.
Integration Merge or rebase resolves the relationship between branches. A conflict means the team must decide between incompatible changes.

Important concepts

Commits, branches, and remotes serve different purposes.

Understanding the differences prevents changes from being shared or overwritten unexpectedly.

Commit and hash

A commit records selected content and its relationship to history. It is identified by a hash, not an ordinary filename.

Branch

A branch is a movable reference into history, not a complete copy of the entire project. It isolates a change before integration.

Fetch, pull, and push

Fetch retrieves information from a remote. Pull usually combines fetch with integration according to configuration. Push sends a local branch.

Merge and rebase

Merge connects histories; rebase moves commits onto a different base. Both approaches have team rules and risks.

.gitignore

It prevents untracked files matching its rules from being added. It does not remove a secret that has already been committed.

Benefits and limitations

History only helps when paired with team discipline.

Benefits

traceable and comparable code changes
offline work with local history
branches for parallel development and review
integration with CI, releases, and main-branch protection rules

Common mistakes

treating a commit as an off-device backup or publication of the change
committing a secret and later only deleting it without rotating access
overwriting shared history with a force push without agreement
submitting large, unrelated commits that cannot be reviewed effectively

When it makes sense

For source code and configuration that need a history.

Git is suitable for everything from a small project to a team product. It provides the most value when changes are divided into readable commits and their integration includes tests, review, and clear release rules.

It is not a replacement for database backups, user-file backups, or a secrets manager. Data and deployments have their own lifecycles, even if their management configuration is versioned.

What to consider

Readable history is part of change quality.

Version-control practices affect review, incident response, and future maintenance.

divide changes into meaningful commits with a clear intent
protect the main branch with review and mandatory CI checks
do not commit secrets; revoke or rotate them if exposed
agree on team rules for merge, rebase, and force push
before rewriting history, check who may already depend on it

Common questions

Git without common misconceptions

Is Git the same as GitHub?

No. Git is a version control system; GitHub is one service for hosting and collaborating on Git repositories.

What is the difference between commit and push?

A commit stores a change in local history. Push sends a branch to a remote repository.

Is a branch a copy of the project?

No. A branch is a reference in history that allows changes to be developed separately.

What should I do after accidentally committing a secret?

Revoke or rotate the credential as soon as possible. Merely deleting the file does not guarantee that the secret has disappeared from shared history or clones.

How I maintain development quality

I connect changes with tests, review, and a repeatable process.

In PHP projects, I use Git worktrees, CI, and quality gates so a change can be safely verified before it reaches production.

How I approach testing and quality Discuss your project without obligation