Git was created in 2005 for the development of the Linux kernel and is now widespread in software development. If you develop software, configure servers by script, or use infrastructure as code, you almost always work with Git. Platforms such as GitHub, GitLab, Azure Repos, or Bitbucket add browser-based collaboration, permissions, reviews, and automation to Git.
How Git works
- Snapshots: According to the official Git book, Git stores data as a series of snapshots of a miniature file system, not as a list of individual file changes.
- Distributed and local: Every working copy contains the complete history. Most operations therefore need only local files and also work without a network.
- Integrity: Everything is checksummed before it is stored and is referred to by that checksum. Unnoticed changes to the history are therefore detected.
- Three states: A file is modified, marked for the next snapshot, or permanently stored; in Git terms, modified, staged, and committed.
The most important everyday terms:
- Commit: a stored snapshot with a description, author, and timestamp
- Branch: a line of development in which a change is created independently of the main line
- Merge: combining two branches
- Remote: a remote repository with which snapshots are synchronized via push and pull
- Pull request: on platforms, the request to merge a branch into the main line after review
Typical team workflow
- Create a separate, short-lived branch for each task.
- Work in small, well-described commits.
- Open a pull request that is tested automatically, see CI/CD.
- Have the change checked in a code review.
- After approval, merge into the main branch and delete the branch.
- Mark release versions with tags so that every version can be restored unambiguously.
A file named .gitignore defines what never belongs in the repository, for example dependencies that Composer reinstalls, or local configuration files.
Git beyond software development
- Maintaining IT's PowerShell and automation scripts in a traceable way
- Versioning configurations of firewalls, servers, or cloud environments as files
- Keeping technical IT documentation in Markdown format with a change history
- Publishing website content through reviewed pull requests
Security
- No secrets in the repository: Git forgets nothing. A password that has been checked in once remains in the history, even if the file is deleted later. GitHub describes how such data can be removed afterward and emphasizes that affected credentials must nevertheless be replaced immediately.
- Control access: Assign rights per repository, protect platform accounts with multi-factor authentication, and revoke tokens and SSH keys during offboarding.
- Protect the main branch: Protected branches require reviews and successful checks before merging and prevent the history from being overwritten.
- Back up: A hosted repository is not a backup. Important repositories belong in the backup strategy.
How it differs
Git is the software; GitHub or GitLab are platforms that host and extend Git repositories. Versioning in SharePoint or OneDrive stores older versions of individual documents but offers no branches, no merging, and no reviews. A backup protects data against loss. Git documents who changed what, when, and why.
Frequently asked questions
Is Git worthwhile for small projects too?
Yes. Even for a single person, Git provides a complete history, the ability to restore earlier states, and branches in which ideas can be tried out safely. The effort is low, because a repository is created with a single command.
How do you undo a change?
On shared branches, git revert creates a new commit that reverses the effect of an earlier commit. The history is preserved and remains traceable for everyone. Commands that rewrite history are intended only for local snapshots that have not yet been shared.
Does Git replace a backup?
No. Distributed copies help if a computer fails, but they do not protect against accidentally deleted repositories on the platform, locked accounts, or ransomware. That requires a separate backup.