Dotfiles are configuration files whose names begin with a leading period, which on Unix-like systems hides them from a normal directory listing. They live in a user’s home directory and hold personal settings for individual programs: .bashrc and .bash_profile for the Bash shell, .vimrc for the Vim editor, .gitconfig for Git, .ssh/config for SSH, and many more. The leading dot is a convention, not a special file type; tools simply agree to look for these specific names, and the shell omits dot-prefixed entries from listings unless asked to show them, keeping the home directory visually uncluttered.
The shell’s startup files are the canonical example, and the Bash manual specifies exactly when each is read. When Bash starts as an interactive login shell it reads /etc/profile and then the first of ~/.bash_profile, ~/.bash_login, or ~/.profile that exists, while a non-login interactive shell reads ~/.bashrc instead (https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html). This split is the source of a perennial confusion: settings that should apply to every shell often need to live in, or be sourced from, .bashrc, while one-time login setup belongs in .bash_profile. Understanding which dotfile runs in which situation is most of what it takes to configure a shell predictably.
Because dotfiles are plain text and accumulate a user’s hard-won customizations, aliases, environment variables, prompt tweaks, key bindings, completion settings, a culture grew up around versioning them. Developers put their home-directory configuration under version control, typically in a Git repository simply called “dotfiles”, so that setting up a new machine becomes a matter of cloning the repo and symlinking the files into place. This makes a personal environment reproducible and portable across laptops, servers, and containers, the same way infrastructure-as-code makes a server reproducible.
Sharing dotfiles publicly turned them into a minor genre of open source. People publish their dotfiles repositories so others can borrow a clever prompt, a useful alias, or a complete shell setup, and tooling sprang up to manage the mechanics: bare Git repositories tracking the home directory, symlink managers, and bootstrap scripts that install the right files and dependencies. The trade-off is that public dotfiles must be scrubbed of secrets, since API keys or tokens accidentally committed to a .bashrc or .netrc become a real security exposure.
At bottom, dotfiles reflect a Unix assumption that configuration is just data in files the user owns, not state hidden inside an application or a binary registry. That openness is why a single text file can be read, edited with any editor, diffed, version-controlled, and copied between machines. The dot prefix is a small ergonomic detail, but the underlying idea, that your environment is a set of editable files you control, is a defining trait of how Unix-like systems are configured.