What is Git?
Git is a free, open source distributed version control system that records changes to files as a history of commits. It lets you compare versions, develop changes on branches and combine work from different people. Git works on your computer. GitHub is a separate platform that hosts Git repositories and adds collaboration tools. Saving a file, committing a change and uploading it are three different actions.
For a broadband engineer or home lab user, that distinction matters. Router configuration templates, scripts, network documentation and infrastructure definitions can have a reviewable history without depending on a constant internet connection. Remote collaboration uses your connection when you exchange repository data; ordinary local commits do not.
Git and GitHub: what is the difference?
Question | Git | GitHub |
|---|---|---|
What is it? | Version control software | A development platform that hosts Git repositories |
Where is history stored? | In a local repository, with optional other copies | In repositories hosted on the platform |
Does a local commit need internet? | No, when required objects and tools are local | Uploading that commit needs access to the host |
What supports review? | Branches, commits and differences | Pull requests, discussions and review controls |
Can I use one without the other? | Yes, including with other hosts or no host | GitHub also offers browser and desktop workflows |
A repository, often shortened to repo, contains a project's recorded history and references to versions. A clone is a local repository created from another repository. A fork on GitHub is a separate hosted repository related to an existing project; you normally clone your fork to work locally. Neither a fork nor a pull request is another name for a Git branch.
GitHub's own explanation distinguishes the underlying version control system from the hosting and collaboration platform. Git can also be used with GitLab, other servers or a repository on your local network. You do not need a GitHub account to practise Git locally.
How does Git record a project?
Git's useful mental model is a sequence of project snapshots. A commit points to the recorded file tree rather than being merely a text patch. Unchanged file content can be reused across snapshots. This does not mean Git stores a completely independent physical copy of every file each time.
A blob stores file content. Its filename is supplied by the surrounding tree, rather than stored as the blob's identity.
A tree connects names and modes to blobs and other trees, describing the recorded directory structure.
A commit refers to a tree, its parent commit or commits, authorship information and a message.
A branch is a movable reference to a commit. HEAD normally identifies the branch currently checked out.
Parent links form a directed acyclic graph of history. An initial commit has no parent, an ordinary commit has one, and a merge commit can have two or more. A diff is a comparison calculated between selected states. Git can also compress objects and store delta representations in packfiles, so the snapshot model and physical storage optimisation coexist.
Object identifiers are hashes, often shown in abbreviated form. SHA-1 is Git's default repository object format; Git also supports SHA-256 where enabled. The official git init documentation currently warns that the two repository formats do not interoperate. An object hash identifies content; it is not encryption or proof that the code is safe.
Working tree, staging area and commit
The working tree is the set of files you edit. The staging area, also called the index, describes the content intended for the next ordinary commit. The current commit is the recorded snapshot referenced by HEAD. Understanding these three states explains most beginner surprises.
Action | What it changes | How to inspect it |
|---|---|---|
Edit or save a file | Working tree | git diff |
git add router.txt | Index captures the current file content | git diff --cached |
git commit -m "Explain change" | Creates a commit from the index | git log and git show |
git push origin main | Updates the selected remote branch | Inspect the remote and push result |
git add does more than mark a filename for later collection. It stages the content present when the command runs. If you edit the file again, those later edits are unstaged until you add them. git diff compares working files with the index; git diff --cached compares the index with HEAD. Check both before committing.
The diagram below separates this local workflow from communication with a remote. A remote can be GitHub, another hosting service or a server you control.
Techie Broadband test: which version gets committed?
We reproduced the following sequence in an isolated local repository using Git 2.51.1 on Linux. There was no configured remote. The file router.txt first contained “version one”, which was committed. We then saved “version two”, ran git add router.txt, and saved “version three” without adding it again.
Point in the test | Working file | Staged content | HEAD content |
|---|---|---|---|
Before the second commit | version three | version two | version one |
After the second commit | version three | version two | version two |
Before committing, git status --short returned MM router.txt. The first M showed a staged modification and the second showed another modification in the working tree. git diff --cached showed the change from version one to version two. git diff showed the separate change from version two to version three.
Running git commit -m "Record staged version two" recorded version two. It left version three in the working file and returned a single unstaged modification in status. No upload occurred. This is a reproducible command behaviour test, not an ISP or hosting performance measurement.
The practical lesson is to review the staged diff, rather than assume the last saved file is the version you are about to commit. Staging lets you deliberately separate one logical change from the next. For a router template, that could mean committing a documented DNS change while leaving an unfinished VLAN edit out of that commit.
Branches, merges and rebases
A branch lets a line of development advance independently. Creating a branch initially adds a reference rather than duplicating the entire project. Switching branches updates the checked out state; local modifications may travel with you when compatible, or prevent the switch when they would be overwritten. A branch is not a separate disk folder.
A merge integrates another history into the current branch. If your branch tip is already an ancestor of the other tip, a fast forward can simply move the branch reference. If histories have diverged, a normal merge can create a new commit with multiple parents. Automatic integration does not guarantee that the resulting application behaves correctly.
A conflict means Git could not reconcile some changes automatically. For example, two people may edit the same router setting differently. Inspect git status, review the competing content, resolve it deliberately, stage the resolved files and complete the merge. Run the relevant configuration checks or tests. Starting with a clean working tree makes it easier to abort a failed attempt.
Rebase reapplies commits on a different base. Recreated commits normally have different identifiers because their parentage or other contents change. This can produce a linear history, but rewriting commits already used by colleagues needs coordination. Follow the project's policy rather than treating rebase or a force push as a universal repair.
Clone, fetch, pull and push
Command | Purpose | Important distinction |
|---|---|---|
git clone URL | Create a local repository from another | Normally also checks out an initial branch |
git fetch origin | Download objects and update tracking references | Does not integrate changes into your checked out branch |
git pull --ff-only | Fetch and integrate by fast forward | Refuses integration when histories have diverged |
git push origin main | Send required objects and update a remote reference | Can be rejected by permissions or history rules |
origin is a conventional remote name, not a special server or a synonym for GitHub. main is a branch name, not a guarantee about every project. origin/main is normally a local remote tracking reference representing the last fetched state of that remote branch. Your local main branch can be ahead, behind or divergent.
Fetching is useful when you want to inspect changes before integrating them. Pull combines fetching with integration. Its strategy depends on options, configuration and Git version; the explicit --ff-only example avoids relying on a default. A push transfers necessary data absent from the destination, rather than uploading every file from every historical snapshot.
A normal clone provides extensive local history, but there are important exceptions. A shallow clone truncates history, while a partial clone omits selected objects and can fetch them when needed. Sparse checkout reduces the files visible in the working tree. These are different mechanisms, and missing objects can limit offline work.
A practical first Git workflow
Install Git using the official installation guidance for Windows, macOS or Linux, then run git --version. The local examples below were checked with Git 2.51.1. Use a new practice directory and an ordinary text editor. Do not run an unfamiliar sequence in a repository containing important unfinished work.
Create a new folder called router-notes, open a terminal there and run git init -b main.
Set repository specific authorship with git config user.name "Your Name" and git config user.email "you@example.com". Replace the placeholders with your intended commit identity.
Create README.md in your editor with a short description of your practice project.
Run git status, then git add README.md, then git diff --cached.
Run git commit -m "Document router notes", followed by git log --oneline.
Create and switch to a branch with git switch -c dns-notes. Edit README.md, review git diff, stage it and commit with a descriptive message.
Return with git switch main, then run git merge --ff-only dns-notes. In this isolated example, main has not advanced independently, so the merge can fast forward.
The name and email configuration records authorship, not your hosting login. Commits can expose that identity when shared, so choose the address you intend to publish. Setting it without --global here affects this practice repository. Configuring an identity does not authenticate you to GitHub.
Connecting the practice project to GitHub
If you want to share this new project, create an empty repository on your chosen host. For this workflow, avoid separately initialising it with a README, because that creates another starting history. Copy the repository's actual clone URL, add it with git remote add origin YOUR_REPOSITORY_URL, inspect git remote -v, and send main with git push -u origin main. Replace the uppercase placeholder; it is not a literal address.
For an existing team repository, clone it and follow its contribution instructions instead. GitHub command line access commonly uses HTTPS credentials through a credential manager or token, or SSH with a key. Your normal account password is not a substitute for the required HTTPS Git credential. Never paste a secret into a committed file.
Where Git fits in review, CI and deployment
A GitHub pull request proposes merging changes and gives reviewers a place to discuss them. It can show commits, differences and automated check results. Opening one does not itself merge a branch. A pull request is also distinct from git pull, which acts on a local repository.
Git records the source history. Continuous Integration can build and test selected revisions when configured triggers run. Deployment changes what is installed or running in a target environment. A push may trigger those systems if configured, but Git itself does not prove a build passed or deploy a service automatically.
In a home lab, keep useful scripts, example configurations and operating notes under version control. Infrastructure as Code can use that history to support review and repeatable changes. Record a reason for each meaningful change, rather than a sequence of messages saying “update”. Keep credentials, personal data and generated backups outside that tracked content.
How does broadband affect Git?
Local history inspection and commits mainly depend on your computer's storage and processing, assuming the necessary objects are present. Clone and fetch from an internet host use downstream throughput. Push uses upstream throughput. Remote authentication and negotiation also involve latency. A faster broadband package cannot resolve a merge conflict or repository permission failure.
For a UK home connection, check the actual upload and download rates separately. An asymmetric service can download a large repository quickly but take longer to push large data. Full fibre does not imply that every package has equal upstream and downstream capacity. Bandwidth is available capacity; throughput is the transfer rate you actually achieve.
Techie Broadband calculation: payload versus connection speed
These are theoretical transfer examples, not measurements of a repository or broadband provider. Assume decimal megabytes, so 1 MB is 1,000,000 bytes, and sustained payload rates stated in megabits per second. Ideal seconds = payload MB × 8 ÷ rate Mbps. Assume 200 MB for an initial transfer and 5 MB for a later exchange; real Git payloads depend on the repository and objects already present.
Illustrative transfer | At 20 Mbps | At 100 Mbps |
|---|---|---|
200 MB initial download | 80 seconds | 16 seconds |
5 MB subsequent download | 2 seconds | 0.4 seconds |
5 MB push at the stated upload rate | 2 seconds | 0.4 seconds |
The 5 MB example contains 97.5% less payload than 200 MB and takes one fortieth of the ideal transfer time at the same rate. That reduction comes from the assumed amount exchanged, not from changing broadband speed. Moving from 20 to 100 Mbps reduces ideal transfer time by 80%, provided the application really achieves that rate.
Real elapsed time also includes connection setup, authentication, server object preparation, protocol and encryption overhead, competing traffic and local unpacking or checkout work. For a small transfer, those delays can dominate the 0.4 second payload estimate. The rate in the push row must be your upload throughput, not the package's advertised download rate.
Large repositories and binary files
Git works particularly well for reviewable text such as source code and configuration. Large changing binaries can make history and transfers cumbersome. Git LFS stores pointer files in Git while the large contents are handled separately. That introduces another storage and transfer dependency; a repository's Git history alone is not the entire LFS dataset.
Use a shallow or partial clone only when it suits the work. A short lived build job may need limited history, whereas investigation or release work may need older commits and tags. Sparse checkout can reduce the checked out files without automatically eliminating their stored history. There is no single clone option that makes every large repository small.
Security, backups and undoing changes
Treat a repository as a record that other people may retain. A private hosted repository is access controlled, but it is not a licence to include passwords, API tokens or customer records. Adding a filename to .gitignore prevents normal tracking of matching untracked files; it does not untrack an existing file or erase an earlier commit.
If a credential is exposed, revoke or rotate it first. Removing it from the latest file leaves historical copies. History cleanup requires coordination because clones, forks and existing references may retain the content. Follow the host's documented removal procedure rather than assuming that a deletion commit has made the secret safe.
A commit is a useful local recovery point, but a single laptop can still fail. A pushed repository protects the history you sent, not uncommitted files, every local branch, all external large files or every hosting setting. Keep suitable independent backups for what matters. Do not confuse version control with complete disaster recovery.
Need | Relevant mechanism | Important limit |
|---|---|---|
Remove a file from the next commit | git restore --staged FILE | Restores its index entry from HEAD; leaves working edits |
Reverse an ordinary shared commit | git revert COMMIT | Adds a reversing commit; conflicts are possible |
Inspect a previous local branch position | git reflog | Local reference history can expire |
Move a branch to another commit | git reset | Mode controls index and working files; --hard can discard work |
Replace FILE or COMMIT with the intended path or identifier. git restore without --staged normally restores working files from the index, which can discard unstaged edits. Reverting a merge needs a choice of mainline parent and additional care. Inspect status and make a recoverable copy before an operation that discards content.
For recovery details, consult the official reflog and reset manuals. Their behaviour depends on the available local history and the selected reset mode.
Troubleshooting: identify the layer first
Symptom | What to check | Useful next step |
|---|---|---|
Nothing to commit, but a file changed | Staging state, ignore rules and correct directory | Inspect git status, git diff and git diff --cached |
Commit exists locally but not on GitHub | Selected branch, remote and push result | Inspect git remote -v and git status -sb |
Push rejected as non fast forward | Remote branch has history your update would replace | Fetch, inspect and integrate using the team's policy |
Authentication or permission denied | Credentials, remote URL and repository access | Check the host's authentication guidance |
Clone or fetch is slow | Payload, transfer direction, network and local work | Separate transfer from unpacking and checkout |
Merge or rebase stopped | Unresolved files and operation in progress | Read git status and resolve or abort deliberately |
An “ahead” count is relative to the local tracking reference and can be stale until you fetch. A successful broadband speed test does not prove your repository host is responding normally. Equally, an authentication rejection is evidence that a service replied, rather than proof that your access line is too slow. Use the actual command output to choose the next investigation.
Frequently asked questions
Is Git the same as GitHub?
No. Git is distributed version control software. GitHub hosts Git repositories and adds collaboration tools such as pull requests. You can use Git locally or with other hosts.
Can I use Git without an internet connection?
Yes, for ordinary local work when the required repository objects and tools are available. Exchanging data with an internet remote requires connectivity. Partial clones may need the remote to obtain missing objects.
Does git commit upload my files?
No. An ordinary commit records staged content in your local repository. Pushing is the separate operation that sends the required data and updates a remote reference.
Does Git track every saved change automatically?
No. Saving changes the working file. Git records a version when you create a commit, normally after staging the content you intend to include.
Do I need GitHub to learn Git?
No. You can create a local practice repository, commit changes, create branches and merge them without a hosting account.
Can Git version router configurations?
Yes, especially text templates, scripts and documentation. Exclude credentials and sensitive exports. Recording a configuration does not apply it to a router or prove that it is valid.
Key takeaway
Git gives project changes an explicit, inspectable history. Working files are what you edit, the index is what you have selected, and a commit records that selected state. GitHub can host and review the resulting work. Keep local history, remote synchronisation, testing and deployment distinct, and the commands become much easier to reason about.
Sources and verification
Primary documentation checked on 12 October 2026. The conceptual references are Pro Git, second edition; command behaviour was checked against the official Git 2.x manuals and GitHub Docs. The staging and branch examples were reproduced locally with Git 2.51.1. The transfer figures are original calculations with explicit assumptions, not measured broadband results.
Git project: What is Git?, Git Objects, Branches in a Nutshell and Packfiles.
Git command manuals: add, commit, diff, status, init, switch, merge, rebase, clone, fetch, pull, push, restore, revert, reset and reflog.
GitHub Docs: What is GitHub?, pull requests, authentication, sensitive data removal and Git Large File Storage.
To explore the related technical concepts used in this Git guide, visit our broadband terminology guide.
