Also: version control, git branch, git merge, rebase, pull request, source control
Git is a distributed version control system that records the history of a set of files as a graph of snapshots, lets many people work on branches of that history at once, and merges their work back together.
Our take. Almost everyone learns three Git commands in their first week and uses those three for a decade, then loses an afternoon every month to a state they do not understand. The tool is a graph of snapshots and nothing else; an hour spent understanding that graph pays back more than any course on any hosting platform built on top of it.
A commit is a snapshot of every file plus a pointer to its parent, identified by a hash of its contents. Not a diff; a whole tree, stored efficiently.
A branch is a movable label pointing at a commit. Creating one costs nothing, which is why the workflow is built on making them constantly.
A merge joins two lines of history by creating a commit with two parents. A conflict is the tool declining to guess when both lines changed the same lines.
A rebase replays your commits on top of another branch, producing a straight history and new hashes. Cleaner to read; dangerous on anything already shared.
The remote is another copy of the same graph on another machine. Push and pull move commits between copies; nothing is central except by convention.
Every confusing Git situation is a question about the graph. Detached head: you are looking at a commit no branch points to. Diverged branches: two labels moved from a common ancestor in different directions. A lost commit: a snapshot no label points to any more, still in the store for weeks and recoverable by anyone who knows to look in the reflog. People who learn the graph stop being afraid of the tool, because every state has a diagram and every diagram has a way out. People who learn commands as incantations delete the folder and clone again, and lose the afternoon.
The hosting platforms, GitHub and GitLab chief among them, are not Git. They are services that hold a copy of the graph and add the collaboration layer around it: pull requests, code review, issue tracking, automation. The distinction matters for learners because the platform course teaches the product and leaves the graph untaught, and it matters for the GitHub Foundations certificate, which examines the platform and assumes the tool. The software engineering shelf puts version control done properly first in its order, and it means the graph, not the buttons.
In practice
A developer has been working on a feature branch for a week while the main branch moved on. They run a merge, get conflicts in three files, panic, and ask a colleague. The colleague draws the graph: here is the commit you started from, here is where main went, here is where you went, and Git is asking you to decide about the three places both of you touched. Each conflict is resolved by choosing or combining the two versions and committing. Twenty minutes. The developer's next question is whether to rebase instead, and the colleague's answer is the only rule that matters: rebase your own unshared work freely, and never rewrite history someone else has already pulled.
Containers package software to run the same way anywhere; Git records how the software's source changed over time. A build pipeline takes a commit from Git and produces a container from it, which is where the two meet.
Git can move commits over HTTP, and the hosting platforms serve their web interfaces over it, but the version control model has nothing to do with the protocol. A learner confused by a push failing over HTTPS usually has a credential problem, not a Git one.
The hosting platforms expose REST APIs for issues, pull requests and automation. Git itself has no API in that sense; it is a local tool with a wire protocol for syncing graphs.
Key takeaways
→Commits are snapshots in a graph; branches are labels; merges are commits with two parents.
→Every confusing state is a question about the graph, and every one has a way out.
→GitHub and GitLab are services built around Git; learn the tool before the platform.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
This is the complete C# masterclass and covers all C# basics for beginners, intermediates and advanced C# concepts.Lear…
Udemy
FAQ
Git or GitHub: what is the difference?
Git is the version control tool that runs on your machine and records the history. GitHub is a company's service that hosts copies of that history and adds review, issues and automation around it. You can use Git without GitHub; you cannot use GitHub without Git.
Merge or rebase?
Merge preserves what actually happened and produces a history with joins; rebase rewrites your commits onto a new base and produces a straight line. Rebase your own unshared branches to tidy them; never rebase anything others have already pulled, because their copy of the graph will no longer match yours.
Can I lose work in Git?
Rarely, and almost never permanently. A commit stays in the local store for weeks even when no branch points to it, and the reflog records where every branch has been. Uncommitted changes are the exception: commit early, and the tool will keep it.
Sources
The primary text this definition rests on. Read it before you trust ours.
