Automate Your Development Environment Setup with Scripts and Dotfiles

TL;DR

Start with a clean machine rather than migrating backups to avoid accumulating years of leftover software and settings.

Briefing Cornell Notes

Briefing

A repeatable, from-scratch setup for a new development Mac is built by combining a GitHub “dotfiles” repository with install scripts that automate terminal configuration, package installation, editor settings, and a few OS-level tweaks. The payoff is consistency: every fresh machine ends up matching the same workflow without relying on memory or manual reconfiguration—while still letting the user customize the scripts to their own preferences.

Instead of migrating an existing system (and inheriting years of clutter), the workflow starts with a clean install and then pulls down personalized dotfiles from GitHub. The repository is treated as a living configuration: it includes an install.sh entry point plus modular scripts for macOS-specific changes, Homebrew package installs, and editor setup. A key warning sits at the top of the documentation: running these scripts is highly personalized and can modify system settings in ways that may be irreversible. The recommended approach is to fork the repository, inspect what each script does, and then run the forked version on a machine that matches the user’s needs.

The automation begins by cloning the dotfiles repo into the home directory and then running install.sh, which creates symlinks for shell configuration files such as bash profile and zsh prompt/alias setups. The terminal experience is customized through shared prompt code that works across shells, including a prompt that shows Git branch context and indicators for Python virtual environments. After the shell layer is in place, the scripts move into macOS-specific tasks—installing command-line tools, adjusting input behavior (like mouse scroll direction), and setting the desktop icon.

Homebrew is installed and then used as the backbone for command-line tools and GUI apps. The brew.sh script updates and upgrades packages, installs developer tooling (including Python, Bash/Zsh-related components, Git, and other utilities), and switches the default zsh to the Homebrew-provided version. It also configures Git identity (username and email) during the one-time setup. For GUI applications, Homebrew Cask installs a curated list including Google Chrome, Firefox, Sublime Text, Visual Studio Code, Spotify, Discord, and Google Drive, along with preferred fonts.

Editor configuration is handled next. The Visual Studio Code portion installs extensions and copies over custom settings and keybindings, with a safeguard that backs up existing files before overwriting. Sublime Text requires a different flow: the script opens Sublime Text so its package directories exist, then uses package control settings to install packages and applies custom settings from the repository. The process includes manual prompts for permissions and sign-ins (Chrome first, with other services optionally skipped during the demonstration).

Finally, the setup verifies itself: the terminal prompt reflects Git branch status, and Homebrew lists installed formulas and casks. The overall message is practical—automated dotfiles reduce the chance of forgetting an app, extension, or login, and make new-machine provisioning fast enough to be routine. The scripts are maintained so additions (new Brew packages or Cask apps) can be appended to the lists, keeping the environment aligned over time.

Cornell Notes

The core idea is to provision a new development machine from a clean macOS install by cloning a personalized GitHub dotfiles repository and running an install.sh script. The scripts automate symlinking shell configuration (bash/zsh prompts, aliases, Git-aware prompt behavior), installing Homebrew and packages (command-line tools plus GUI apps via Cask), and applying editor settings for Visual Studio Code and Sublime Text. OS-level tweaks like desktop icon changes and input behavior are included as well, with permission prompts handled during setup. Because the scripts can change system settings and may be hard to undo, the recommended path is to fork the repo, review what each script does, and then run the forked version on your own machine.

Why does the workflow prefer a fresh install over migrating an old Mac setup?

It avoids carrying forward years of accumulated clutter—leftover software, outdated settings, and backup baggage. Files and photos are assumed to be synced via cloud services, so only specific items are transferred manually (e.g., via a thumb drive). The result is a clean baseline, then a controlled reinstallation of only the desired development tools and configurations.

What makes the dotfiles approach “repeatable” instead of just another checklist?

The setup is driven by scripts stored in the dotfiles repository. install.sh acts as the main entry point, then calls modules like macOS-specific scripts and brew.sh. Those scripts clone/copy configuration files, install packages, and apply editor settings automatically, so the same environment is recreated each time without relying on memory.

What’s the most important safety caveat before running these scripts?

The repository is highly personalized and can modify system settings and file locations in ways that may be irreversible. The documentation emphasizes understanding what the scripts do before running them. The practical recommendation is to fork the repo, inspect the changes, and run the forked scripts rather than blindly executing someone else’s configuration.

How does the setup customize the terminal experience?

Shell configuration files are symlinked into place (bash profile and zsh prompt/alias files). A shared prompt implementation provides Git-aware context—showing the current branch when inside a Git repository—and also indicates when a Python virtual environment is active. The prompt and related settings are applied for both bash and zsh.

How are software installations handled across command-line tools and GUI apps?

Homebrew is installed first, then brew.sh updates/upgrades packages and installs command-line tools (including Python and Git-related tooling). For GUI apps, Homebrew Cask installs a list of applications such as Google Chrome, Firefox, Sublime Text, Visual Studio Code, Spotify, Discord, and Google Drive, plus preferred fonts.

Why does Sublime Text require a different automation flow than Visual Studio Code?

Sublime Text needs to be opened so its package directories and settings structure exist before custom packages/settings can be installed. The script opens and closes Sublime Text during setup, then uses package control settings to install packages and copies custom configuration files from the repository into the correct locations.

Review Questions

What specific components of a development environment does the install.sh script automate, and how do those components interact (shell, packages, editors, OS settings)?
What risks come with running personalized dotfiles scripts, and what mitigation steps are recommended?
How does the workflow verify that the environment was configured correctly after installation?

Key Points

1
Start with a clean machine rather than migrating backups to avoid accumulating years of leftover software and settings.
2
Clone a personalized dotfiles GitHub repository and run install.sh as the single entry point for a full environment rebuild.
3
Treat the scripts as system-modifying automation: review them first, then fork the repo for your own machine to avoid overwriting your preferences unexpectedly.
4
Use symlink-based shell configuration to standardize bash/zsh prompts, aliases, and Git-aware terminal behavior across machines.
5
Rely on Homebrew plus Homebrew Cask to install both command-line tools and GUI apps in a consistent, scripted way.
6
Automate editor setup by copying Visual Studio Code settings/extensions and by using Sublime Text’s package control flow that requires opening Sublime at least once.
7
Expect and handle one-time permission prompts and sign-in steps during setup so the machine is fully usable when the scripts finish.

Highlights

The environment is recreated from scratch by cloning a dotfiles repo and running install.sh, producing the same terminal, package set, and editor configuration every time.

A prominent warning notes that these scripts are personalized and can make irreversible changes—forking and reviewing the scripts is the safer path.

Homebrew is the installation backbone: brew.sh installs command-line tools and uses Cask for apps like Google Chrome, Sublime Text, Visual Studio Code, Spotify, and Discord.

Visual Studio Code setup includes extension installation plus backups of existing settings/keybindings before overwriting.

Sublime Text automation requires opening Sublime Text so package directories exist, then applying package control settings and custom configuration.

Topics

Dotfiles
Development Environment Setup
Homebrew Cask
Shell Prompt
Editor Configuration