Dotfiles and One-Command Developer Machine Setup

The problem: every new laptop costs a day

Every developer rebuilds a machine sooner or later: a new laptop, a reinstall after a crash, a lab PC wiped every semester. It usually happens from memory, with half the settings missing and a day lost. The same pain hits student societies and small teams: every new member spends their first session installing Node, Git, an editor and fixing PATH instead of writing code.

A careful, tested setup script fixes this, and building one exercises most of the terminal and Git skills a developer needs: package managers, PATH, shell startup files, symlinks, permissions, error handling and CI.

What already exists and the gap

• GNU Stow is a symlink farm manager: organise files in folders and it links them into place.
• yadm wraps Git for dotfiles and adds per-machine classes, encryption and bootstrap scripts.
• chezmoi is a feature-rich dotfiles manager with templates, secret manager integration and Windows support.
• The bare Git repository pattern keeps dotfiles in a Git directory pointed at the home folder, with no extra tool.

These tools manage files very well. What they leave to you is the bootstrap: installing packages across operating systems, making a second run safe, proving it works on a clean machine, and documenting it for someone else. Most personal dotfiles repositories are also untested. The gap here is a tested, documented, idempotent setup that a team could adopt, not just one person's config.

What you build

• Repository layout with one folder per tool (shell, git, editor, ssh template, packages).
• install.sh using strict mode, checking its environment, detecting the operating system and installing from package lists.
• Linking with backups and an uninstall script.
• Secrets kept out of Git: a local file sourced by the shell, with only a template committed.
• CI that lints the scripts and runs the installer on clean runners.

Users: you first, then a student society or small team who adopt it as their onboarding script with a shared base and personal overrides.

The technically interesting part

Idempotency. Running the installer twice must produce the same machine with no errors and no duplicate lines in startup files. That means every step checks before it acts: is the package already installed, is the link already pointing at the right file, is the line already in the file. This is the same property configuration tools such as Ansible are built around, and learning it on a small script makes the idea stick.

Show your supervisor a CI job that runs the installer, captures a snapshot of the relevant files and installed packages, runs it again, and diffs the two snapshots. An empty diff is your proof.

How to evaluate it

• Clean install: time from fresh Ubuntu container or runner to working environment, measured across 3 runs.
• Idempotency: second-run diff is empty on Ubuntu and macOS.
• Quality: zero ShellCheck warnings; shell tests with bats-core for the helper functions.
• Adoption: ask 3 classmates or society members to use it on their own machine and record problems they hit.

Suggested plan

1. Week 1: inventory your current setup, design the layout, write the package lists.
2. Week 2: installer with OS detection, linking, backups, dry-run.
3. Week 3: CI on Ubuntu and macOS, idempotency test, secret scanning.
4. Week 4: team profile, user trials, README and write-up.

Path to a product

This is a learning and portfolio project, and it should be honest about that. The realistic users are you, your society and small teams who want a documented onboarding script. A well-tested template that others fork is a fine open source outcome, and the same skills lead directly to DevOps and platform internships, where "set up new developers in one command" is a common real task.

Scope warning

Do not write your own configuration management tool. Do not support every Linux distribution; Ubuntu, WSL and macOS are enough. Never commit tokens, private keys or machine-specific secrets, and read every line you copy from other people's dotfiles before adding it to yours.

Learn what you need on Sefism

• DevOps and cloud roadmap : where shell scripting and CI fit in the wider path.
• DevOps and cloud cheat sheet : quick reference for CI pipelines and Linux basics.
• Greg's Wiki: BashGuide : write Bash that does not break on spaces and errors.
• ShellCheck : the linter your CI runs on every push.
• Windows Subsystem for Linux Documentation : set up and test the WSL path properly.
• How to learn Git and GitHub properly : the Git habits this repository depends on.

Get help with this idea

This project is small, so the difference between an average and a strong result is in testing and documentation. A mentor can help you decide what belongs in scope and how to prove idempotency convincingly. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session