Git is a distributed version-control system that stores project history as snapshots and lets contributors work locally before syncing through remotes.
Git is a distributed version-control system. It records project history as commits, lets people work with a complete local copy of that history, and can synchronize changes with shared remote repositories.
Git is not GitHub. Git is the version-control tool and data model. GitHub, GitLab, Codeberg, Bitbucket, and similar services host repositories and add collaboration features around Git.
Why Git is distributed
In a distributed system, each clone has its own repository history. A contributor can commit locally, inspect old changes, create branches, and compare revisions without asking a central server for every operation.
Remote repositories still matter. Teams usually share a remote so people can exchange changes, review work, publish releases, and keep a common project location. The difference is that the remote is a synchronization point, not the only place where history exists.
This model helps open-source projects because contributors can copy the public repository, experiment in their own branch, and propose changes without needing direct write access to the main project.
Snapshots, not just changed lines
Git's official documentation describes its model as snapshots. Each commit represents the state of tracked files at that point, with metadata linking it to earlier commits.
Users often experience this as a list of changed lines, because Git tools show diffs between snapshots. The diff is a comparison view. The commit itself is a recorded project state with an identifier, author information, message, and parent relationship.
That structure lets Git answer practical questions: what changed since the last release, which commit introduced a behavior, and what would happen if one branch were merged into another.
Working tree, staging area, local repository, and remote
The working tree is the editable project folder. This is where files are changed by a text editor, build tool, or other program.
The staging area is a preparation step for the next commit. It lets a person choose which changed files or hunks belong together before the commit is recorded.
The local repository stores commits and branches on the user's machine. A remote repository is another copy that can receive or provide commits. A common remote named origin is just a convention, not a special GitHub feature.
Common Git actions in plain language
Clone means copy a repository so the user has project files and history locally. It is often the first action when someone wants to inspect source code or contribute.
Commit means record a selected change in the local repository. The commit message should help later readers understand the purpose of the change.
Pull and fetch bring remote changes toward the local repository. Push sends local commits to a remote. Branch creates or selects a line of work. Merge combines one line into another.
These terms identify concepts, not a complete command tutorial. Real projects also have authentication, review rules, protected branches, and contribution policies that shape how commands are used.
Tags, releases, and history readers
Tags give names to particular commits. Open-source projects often use them to mark releases, such as the commit used to build a versioned package.
A release page may include binaries, source archives, notes, and a tag reference. The tag connects those materials back to repository history, but the tag alone does not prove how a binary was built or signed.
Readers who inspect release history should separate three layers: Git commits, hosted release pages, and downloadable artifacts. Git explains the source timeline. Release automation and packaging explain how artifacts are produced from that timeline.
Git, GitHub, and hosting platforms
GitHub is a hosted collaboration platform built around Git repositories. It adds accounts, issues, pull requests, code review, actions, package publishing, permissions, and project pages.
Git can be used without GitHub. A team can host Git on another platform, use a self-hosted service, or exchange patches through other workflows. The host changes collaboration features, not the fact that Git repositories contain commits, branches, tags, and remotes.
Choose a Git host based on project needs such as permissions, issue tracking, CI integration, account model, export options, and community expectations. That is a hosting decision, not a definition of Git.
Local changes and remote changes
Git beginners often hit confusion when local history and remote history both changed. The tool needs to reconcile the two sequences before one shared result can exist.
Fetching updates brings remote information into view without necessarily changing the working branch. Pulling usually combines remote changes into the current work, depending on project configuration. Pushing asks the remote to accept local commits.
If the remote refuses a push, the cause is often protection or divergence. A protected branch may require a pull request. A diverged branch may need the user to integrate remote changes first. The error is a coordination signal, not a reason to delete work blindly.
Merge conflicts are decision points
A merge conflict appears when Git cannot safely combine changes by itself. The conflict usually points to the same lines or nearby file regions changing in different ways.
The right answer is not always one side or the other. A person may need to preserve both edits, rewrite the result, update tests, or ask the other contributor why the change was made.
Good projects document how conflicts should be handled before release branches, generated files, lockfiles, or translations are edited. The technical conflict is often smaller than the product decision behind it.
Beginner confusion points
| Git term | Plain meaning | What the reader sees | Not the same as | Related Resource |
|---|---|---|---|---|
| Repository | Project history and files | A project folder or hosted repo page | A website account | Version control |
| Commit | Recorded change point | A hash, message, author, and diff view | A file save | Changelog |
| Branch | Separate line of work | A name such as main or feature-x | A full project copy | Branching strategies |
| Remote | Another repository location | origin, hosted URL, or server path | The host company itself | Choose a Git host |
| Pull request | Hosted review proposal | Discussion around proposed commits | A Git command | Pull requests |
How Git supports open-source collaboration
Open-source projects use Git to make changes reviewable. A contributor can create a branch, commit a focused change, push that branch to a place the project can see, and ask maintainers to review it.
Maintainers can inspect the diff, run checks, request changes, and merge only after the project rules are satisfied. The final history gives future contributors a path back through decisions, regressions, releases, and fixes.
Git does not create a healthy workflow by itself. Projects still need useful READMEs, contribution guidelines, tests, release notes, and maintainer judgment.
Desktop clients and command-line Git
Graphical Git clients can make history, diffs, branches, and conflicts easier to see. Command-line Git can be more precise, easier to document, and available in more automated environments.
The client does not change the repository model. A desktop app, editor integration, hosting website, or terminal command can all operate on commits, branches, and remotes.
When instructions mention a Git command, readers using a graphical client should look for the equivalent concept. For example, "commit" still means recording a change, and "push" still means sending commits to a remote.
Reading a repository before contributing
Before editing, inspect the repository layout. Look for a README, license, contribution guide, issue templates, recent commits, release tags, and CI status. These clues explain how the project expects Git history to be used.
Branch names can also tell a story. A project may use main for current development, release branches for supported versions, and short-lived branches for features or fixes. Another project may keep a simpler model.
Commit history reveals norms. Some projects prefer small atomic commits. Others squash changes during merge. Following the local pattern reduces review friction and keeps history understandable.
Authentication and permissions are separate from Git
Git can move data between repositories, but hosted platforms decide who is allowed to push, open pull requests, approve changes, or publish releases.
Authentication failures often come from expired tokens, missing SSH keys, account permission changes, or protected branches. The repository model may be fine even when access is denied.
That distinction matters for troubleshooting. A user who cannot push to a protected main branch may need to push to a personal fork and open a pull request, not change Git history locally.
History rewriting needs caution
Git can rewrite local history through actions such as amending, rebasing, or resetting. Those tools can produce cleaner review branches, but they can also confuse collaborators when used on shared history.
A contributor working alone on an unpublished branch has more freedom to tidy commits. A maintainer working on a shared branch needs project rules and communication before changing history that others may have copied.
The safe beginner rule is simple: understand what is local, what is already pushed, and what other people may be using before rewriting anything.
When Git is not the whole answer
Git stores project history, but it does not manage every collaboration task. Issues track work, pull requests organize review, CI checks validate changes, releases publish artifacts, and documentation explains how people should participate.
A private folder can use Git without any hosting platform. A public open-source project usually needs more surrounding practice: contribution guidelines, license clarity, review expectations, security reporting, and release communication.
Use Git to understand the history layer. Use the related Development resources when the decision is about branching policy, pull-request flow, code review, or choosing a host.
When to learn Git next
Learn Git when a project asks you to clone a repository, submit a patch, open a pull request, inspect source history, or understand release tags.
Start with the concepts before memorizing commands. Repository, commit, branch, merge, remote, clone, pull, and push explain most beginner situations. The exact commands are easier to learn once the data model is clear.
If the question is whether a project should use a simple flow, GitHub Flow, Git Flow, trunk-based development, or release branches, move to the branching strategy guide rather than expanding Git into a workflow article.