Git definition
Version control is a system that records every change made to files, usually source code, so teams can see who changed what and why, work in parallel on branches, review changes and restore any earlier version. Git, created by Linus Torvalds in 2005, is the dominant version control system, used through platforms such as GitHub, GitLab and Bitbucket.
How does version control work?
Files live in a repository. Each time a developer saves a meaningful set of changes, they create a commit: a snapshot of the project with a message, an author, a timestamp and a link to the previous commit. Together, commits form a history that can be inspected, compared and rolled back. Git is distributed, so every clone holds the full history and most operations work offline, unlike older centralized systems such as Subversion.
A typical team workflow looks like this: clone the repository, create a branch for a change, commit work in small steps, push the branch to a shared host, open a pull request, have teammates review it while CI runs tests, then merge it into the main branch. The host keeps the discussion, approvals and test results attached to the change permanently.
Key Git concepts
- Repository: the project and its complete history.
- Commit: a snapshot of changes with a message and author.
- Branch: an independent line of development.
- Merge and rebase: two ways to combine work from different branches.
- Pull request or merge request: a proposed change for review before merging.
- Tag: a named marker for a specific commit, often a release version.
- Remote: a shared copy of the repository, such as one on GitHub.
- Ignore file: patterns for files that should never be tracked, such as build output.
Branching strategies
Trunk-based development keeps branches short-lived, often hours or a day or two, and merges into the main branch frequently, using feature flags to hide unfinished work. It pairs naturally with continuous integration and delivery. GitHub Flow is similar: branch from main, open a pull request, merge and deploy. Git Flow uses long-lived develop and release branches and suits products with versioned, scheduled releases, but it slows integration and creates painful merges for teams that deploy continuously.
Whichever model you choose, protect the main branch: require pull request reviews and passing CI checks before merging, and prevent force pushes that could rewrite shared history. Short-lived branches make each of these rules much easier for the whole team to live with.
Version control best practices
- Make small, focused commits with clear messages explaining why, not just what.
- Use a consistent message convention, such as Conventional Commits, to automate changelogs.
- Never commit secrets; scan for them automatically and rotate any that slip through.
- Sign commits so authorship can be verified.
- Use Git LFS or artifact storage for large binary files.
- Keep pull requests small enough to review properly.
What else belongs in version control
Version control is not only for application code. Infrastructure as code, CI/CD pipeline definitions, database migrations, configuration, documentation, API specifications and design tokens all benefit from history, review and rollback. With GitOps, the repository even becomes the source of truth for what runs in production. Nexzem works in client-owned repositories from day one, so the full history, reviews and decisions stay with the client after handover.