What does Git fetch do?
Fetched branches and/or tags (collectively, “refs”) from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated.
What does Git pull do?
Incorporates changes from a remote repository into the current branch. If the current branch is behind the remote, then by default it will fast-forward the current branch to match the remote. If the current branch and the remote have diverged, the user needs to specify how to reconcile the divergent branches with –rebase or –no-rebase (or the corresponding configuration option in pull.rebase).
More precisely, git pull runs git fetch with the given parameters and then depending on configuration options or command line flags, will call either git rebase or git merge to reconcile diverging branches.
What are git tags?
Tags are ref’s that point to specific points in Git history.
A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit.
Annotated tags, however, are stored as full objects in the Git database. They store extra meta data such as: the tagger name, email, and date.
Example of a tag: v1.0.1
Lightweight Tags: These truly are just a pointer (a reference) to a specific commit hash. If you move the commit, the tag doesn’t move. It has no extra data.
* Annotated Tags: These are actual objects in the database. As the card says, they contain metadata (who tagged it, when, and a message). This is what you would usually use for a software release (e.g., v1.0.0).
What are git refs?
Card 2: What are Git Refs?
Verdict: Technically correct (Implementation view).
The answer provided (“a file that contains a Git commit SHA-1 hash”) is the literal physical definition of a ref.
If you were to open your project folder and navigate to .git/refs/heads/, and open the file named main (or master) in a text editor, all you would see is a 40-character string (the hash).
Context to add to your mental model:
While the card is right, it is helpful to think of “Refs” (References) as the umbrella term for user-friendly pointers.
* Branches are refs.
* Tags are refs.
* Remotes (like origin/main) are refs.
Summary Table
To visualize the relationship between the two cards:
| Concept | What it is conceptually | What it is physically on disk |
|—|—|—|
| Commit | A snapshot of your code. | A file containing the snapshot data + metadata. |
| Ref | A human-readable bookmark (Branch, Tag). | A text file containing the Commit’s SHA-1 hash. |
| Tag | A ref that (usually) doesn’t move. | A ref pointing to a specific moment in history. |
Would you like me to explain the specific Git commands you would use to manipulate these refs safely?
What are releases
Releases are GitHub’s way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software.
With Releases, you can provide links to binary files, as well as release notes describing your changes.
At their core, Releases are based on Git tags. Tags mark a specific point in the history of your project, so they’re a great way to indicate a Release. Releases are ordered by a tag’s date in the following way:
If it’s an annotated tag, the tag object’s date is used.
If it’s a lightweight tag, then the commit object’s date is used.