How do building, tagging, and pushing images work — and registry vs repository vs tag?

Short answer

docker build -t name . builds from the Dockerfile in the build context; the tag names where it can go as [HOST/]PATH[:TAG] (default docker.io, latest). docker push uploads layers to a registry repository. A registry stores images; a repository is one project's image collection; a tag versions it.

Detailed explanation

Building: docker build . sends the build context (the trailing . — Dockerfile plus referenced files) to the builder, which pulls the base and runs each instruction; without -t you get an ID like sha256:9924… that you can docker run but cannot remember — tagging fixes that. Naming structure [HOST[:PORT]/]PATH[:TAG]: HOST defaults to docker.io, PATH is [NAMESPACE/]REPOSITORY (namespace = user/org, library = Official Images), TAG defaults to latest. So nginx = docker.io/library/nginx:latest, docker/welcome-to-docker = docker.io/docker/welcome-to-docker:latest, and ghcr.io/dockersamples/vote:pr-311 points at GitHub's registry. Registry (Hub, ECR, ACR, GCR, or self-hosted Harbor/Artifactory/GitLab) vs repository (one project's images, e.g. docker-quickstart holding :1.0, :latest) is the folder analogy. Push flow from the docs: create a Hub repo, docker login, docker build -t <user>/docker-quickstart ., test with docker run -d -p 8080:8080 <user>/docker-quickstart, version with docker tag <user>/docker-quickstart <user>/docker-quickstart:1.0, then docker push <user>/docker-quickstart:1.0. Retagging an existing image with docker image tag adds a name without rebuilding.

Official docs:Docker docs: Build, tag, and publish

Common mistakes

• Using registry and repository interchangeably.
• Forgetting the trailing . build context or pushing before docker login and a matching namespace.