FAQ
What’s the difference between Git and GitHub?
Git is the version control software itself — it runs entirely on your machine and has no concept of "GitHub." GitHub (and GitLab, Bitbucket, Codeberg, etc.) is a hosting service built around Git: it stores remote copies of Git repositories and adds features Git itself doesn’t have, like pull requests, issue tracking, and CI. You can use Git fully without ever touching GitHub.
What does "detached HEAD" mean, and is it a problem?
It means HEAD points directly at a commit instead of at a branch —
which happens when you check out a specific commit, a tag, or a
remote-tracking branch directly. It’s not an error state; you can look
around, build, and test freely. The only thing to watch for: any new
commits you make while detached aren’t on any branch, so they become
unreachable (and eventually garbage-collected) the moment you check out
something else — unless you first run git switch -c new-branch-name to
give them a home. See How Git Works.
I just made a mistake. How do I undo it?
Depends what you did — see the decision table on
Undoing Changes. As a rule of thumb: if you
haven’t pushed yet, almost anything is fixable with reset, restore, or
rebase -i. If you have pushed, prefer revert over rewriting history.
Deleted a branch by accident? git reflog almost certainly still has it.
Why is Git bad at handling large binary files?
Git computes diffs and deltas assuming text-like content that compresses well between versions. Large binaries (videos, datasets, compiled assets) don’t diff well, so every version is stored close to full size, bloating the repository forever — even if the file is later deleted, old versions remain in history. Use Git LFS (Large File Storage), which stores a small pointer file in Git and the actual binary content in separate storage, for anything like this.
Should I merge or rebase?
Merge when combining a finished feature branch back into main (and
especially anything already pushed/shared) — it preserves exactly what
happened. Rebase when cleaning up your own local, not-yet-shared branch
before opening a pull request, or keeping a long-lived feature branch
up to date with main without a pile of merge commits. Full comparison on
Rebasing & Cherry-Picking.
Should I clone over SSH or HTTPS?
Either works. SSH (git@github.com:user/repo.git) authenticates with a key
pair and never prompts for credentials once set up — generally preferred
for regular contributors. HTTPS
(https://github.com/user/repo.git) works anywhere without SSH access
(e.g. some corporate networks that block port 22) and authenticates with a
personal access token, cached by a
credential helper so you don’t retype it
constantly.
Why do commits show both "Author" and "Committer"?
The author is whoever originally wrote the change; the committer is whoever last applied it to the repository. These are usually the same person, but diverge when a patch is emailed to a maintainer who applies it (author: contributor, committer: maintainer), or after a rebase, which updates the committer date/identity while preserving the original author.
Why doesn’t Git track empty directories?
Git tracks content (blobs) and the trees that reference them — an empty
directory has no content to point at, so there’s nothing for Git to
record. The common workaround is committing a placeholder file inside it,
conventionally named .gitkeep (not a Git feature, just a naming
convention).
Where can I go for more?
- git-scm.com/docs — the official command reference
- Pro Git — the free, official book, covers everything on this site in far more depth
git help <command>orman git-<command>— from your own terminal