As you start to understand the world of infrastructure-as-code for development environments, you eventually start to find yourself looking for better ways to work within that environment. While having a complete, working environment is a powerful feature, there are often parts of the experience that need to be more personal. Enter the dotfiles.
Historically, dotfiles is a reference to the various files and folders that start with a . in Unix file systems. These files control the configuration of applications or environments. This can include settings, preferences, and even special tools. With a more distributed world, developers started moving these files into Git repositories to make them always available and version controlled. GitHub users often create a special repository called dotfiles for this purpose. That said, any repository can be used as a dotfiles repository. Because a dotfiles repository represents settings preferences, it’s not uncommon for those to be public. This has the added advantage that the repository contents are always accessible and available without requiring authentication. There’s some nice
unoffical documentation
on dotfiles that includes samples. An important reminder – this is NOT for credential storage. Keep those securely stored and never keep sensitive account details in a Git repository.
A dotfile repository can be automatically utilized by your development containers. If you select a repository to act as your dotfiles repository in your
personal Codespace settings
, GitHub will clone the repository and link all files starting with a . into your home directory. If you need more power and control, include an install or setup script in the repository to customize the environment. GitHub details this
here
.
If you’re using VS Code and Dev Containers, then you can add your Git repository to the VS Code User Settings and specify a location where the files will be placed. In addition, you can specify the install script that should be run to configure the environment. You can learn more about this process here .
Of course, you can also use dotfiles in your local environments. By cloning your dotfiles repo, you can have your latest settings always shared across environments. After downloading the settings, a simple installation script can put every file in an appropriate place. Taking it even further, linking the files to the repository makes it possible to version and share changes across multiple environments. A special note for Windows users: if you haven’t taken the time to learn about using mklink to create junctions and links, you’re missing out! Being able to have a file in multiple places at once is a powerful addition to your toolbelt!
Hopefully this has given you some basic insights into the wonderful world of dotfiles. There’s a lot to learn from the incredible approaches that people have developed for their environments. Keep exploring and Happy DevOp’ing!