Git vs GitHub: Key Differences

You clone a repository, edit two files, commit, run git push — and the terminal answers ! [rejected] main -> main (fetch first). Nothing is broken: while you were working, a teammate pushed their own commits and your history drifted apart from the remote one. The fix is a single command, git pull --rebase, followed by git push again. Messages like this stop being scary the moment you understand where Git ends and GitHub begins, and what each command actually does.

Git is a distributed version control system that you install on your machine and that keeps the full history of a project locally. GitHub is a cloud service that hosts Git repositories and adds collaboration tools on top of them. In one sentence: Git is the tool, GitHub is the place where the results of that tool are stored, reviewed and discussed.

Git vs GitHub — what is the difference

Git was created by Linus Torvalds in 2005 for Linux kernel development. It tracks changes in code, handles branches, merges work from different developers, rolls the project back to any earlier state, and does all of that offline — the complete history lives on your own disk.

GitHub launched in 2008 and has been owned by Microsoft since 2018. It wraps Git in a web interface and adds pull requests, code review, an issue tracker, CI/CD (GitHub Actions), static site hosting (GitHub Pages) and team permissions. GitHub’s motto is Social Coding: it is not just storage for code, but a platform for both open-source and private projects.

The short answer: Git is the technology, GitHub is a service built around that technology. You can use Git without GitHub, but GitHub cannot exist without Git.

File states in the Git working directory

Git splits every file in your project folder into two groups: tracked and untracked.

1. Tracked files — files that were part of the last snapshot of the project or have already been added to the index. They can be unmodified, modified, or staged for the next commit.
2. Untracked files — everything else: files that were not in the last commit and that you have not added with git add yet.

A file travels through three areas: working directory → index (staging area) → repository.

One command shows the current state of every file:

git status
git status -s   # short format: ?? untracked, M modified, A added to the index

Essential Git commands

The list below is the minimum set that covers day-to-day work.

A typical work cycle

git status              # see what changed
git add .               # stage all changes
git commit -m "Add user validation"
git pull --rebase       # take teammates' commits and replay yours on top
git push                # send everything to the server

git add . vs git add -A vs git commit -am

These three shortcuts look interchangeable and are not:

• git add . stages everything under the current directory, including new files.
• git add -A (also written git add --all) stages everything in the whole repository, no matter which folder you are standing in.
• git add -u stages only files that Git already tracks — new files are ignored.
• git commit -a -m "message" (short form git commit -am) stages and commits tracked files in one step, but it will silently skip a brand-new file you have never added.

Since Git 2.0 git add . and git add -A behave identically when you run them from the repository root; the difference only shows up in a subdirectory.

What commit, fetch, pull and push really do

git commit stores the state of the project: Git records how each file looks at that moment and saves a reference to the snapshot. If a file did not change, Git does not duplicate it — it links to the identical version it already stores, which is why history stays compact.

git fetch contacts the remote repository and downloads data you do not have yet. Afterwards you get references to every remote branch (origin/main and the rest) that you can inspect or merge. Fetch does not change your working copy — merging stays your decision. Use git fetch --all to refresh every configured remote at once.

git pull is fetch plus an automatic merge of the remote branch into the current one. When you clone a repository, Git sets your local branch to track the remote’s default branch (usually main), which is why git pull without arguments knows where to pull from.

git push uploads your commits to the remote repository. It succeeds only if you have write access and nobody has pushed new commits since your last fetch. If a teammate got there first, your push is rejected with a non-fast-forward error: you have to bring their work down and combine it with yours before trying again.

Working with GitHub from the command line

There is no separate set of “GitHub commands” in the terminal. You talk to GitHub with the same Git commands — you simply point the remote at an address on github.com.

Clone an existing project

git clone https://github.com/user/project.git
cd project

Push a local project to GitHub

Create an empty repository on GitHub (without a README), then run:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/user/project.git
git push -u origin main

The -u flag links your local branch to the remote one, so from then on plain git push and git pull are enough.

Check and change the repository address

git remote -v                                   # which remotes are configured
git remote add upstream https://github.com/original/project.git
git remote set-url origin [email protected]:user/project.git   # switch to SSH

Branching, merging and conflicts

Branching lets you keep independent lines of development: a new feature, an experiment or a bug fix never disturbs the main code. Git stores the project as a series of snapshots, and a branch is just a lightweight pointer to one commit — which is why creating a branch takes milliseconds.

git branch                      # list branches
git switch -c feature/login     # create a branch and move onto it
git switch main                 # go back to the main branch
git merge feature/login         # merge the branch into the current one
git branch -d feature/login     # delete a branch that has been merged

git switch (change branches) and git restore (discard changes in files) arrived in Git 2.23 and split the responsibilities of the overloaded git checkout, which used to do both. The older form git checkout -b feature/login still works.

A merge conflict happens when the same line was edited in two branches. Git marks the disputed area in the file with <<<<<<<, ======= and >>>>>>>. You keep the correct version by hand, delete the markers, and finish the merge:

git add ConflictedFile.java
git commit

Tags and releases

A tag is a fixed bookmark on a particular commit. Unlike a branch, a tag never moves forward, which makes it the natural way to mark released versions such as v1.0 or v2.0.1.

git tag v1.0                          # lightweight tag
git tag -a v1.0 -m "First release"    # annotated tag with author and date
git push origin v1.0                  # tags are not sent by a plain git push

On GitHub a tag becomes the basis of a Release — a page with release notes and attached build artifacts, for example a JAR file.

Fork and pull request

A remote repository is a version of your project hosted on a server, for example on GitHub. You can have several remotes, each with its own permissions: read-only, or read and write.

If you want to contribute to a project where you have no write access, use fork — the button that creates a copy of the repository under your own account. The workflow then looks like this:

1. Press Fork on the project page — the copy appears in your account.
2. Clone your copy with git clone.
3. Create a branch, make the changes, commit and git push.
4. Open a pull request against the original repository.
5. The maintainer reviews the code and either merges or rejects it.

Forking is the standard way to take part in open source. GitHub keeps the link between your copy and the original, so you can bring in upstream changes with the Sync fork button or from the terminal:

git remote add upstream https://github.com/original/project.git
git fetch upstream
git merge upstream/main

Where beginners get tripped up

• Committing without staging. git commit records only what you staged with git add. A modified but unstaged file simply will not be part of the commit.
• Running git add . in the project root. That is how target/, .idea/, *.class files and — far worse — passwords from config files end up in the repository. Write a .gitignore before the first commit.
• Pushing without pulling. The ! [rejected] ... (non-fast-forward) error means the server has commits you do not. The answer is git pull --rebase, not git push --force: a force push overwrites someone else’s work.
• Pulling with uncommitted changes. Git refuses to merge over them. Either commit first, or park the changes with git stash and bring them back with git stash pop.
• Detached HEAD. You land there after git checkout <commit hash>. Commits made in that state belong to no branch and are easy to lose — go back with git switch -, or save the work in a new branch first.
• Mixing up the terms. A pull request is a GitHub feature, not the git pull command. They share a word and nothing else.