Note: You can see my zshconfig here.

As developers, we spend a considerable amount of time fine-tuning our environments. Customizing your bash or zsh configuration can significantly enhance your productivity, whether through personalized shortcuts, workflow automation, or optimized command sequences. However, there’s always one looming concern—what happens when you get a new machine?

The problem of environment portability often discourages developers from going deep into shell customizations. Yet, the reality is that shell scripts are as critical as code, and losing them means not only a hit to productivity but also a loss of the efficiency and reliability you’ve built over time. I recently tackled this issue by putting my custom bash and zsh configuration into a source-controlled GitHub repository, and I’d like to share why this was a game-changer for me.

Benefits of Version-Controlled Shell Configurations

1. Easy Environment Setup – When you get a new machine, setting it up to match your old environment can be a daunting task. But when your configuration is stored in a repository, it’s as simple as cloning it and sourcing the files. All your aliases, helper functions, and environment variables are just a git clone away

git clone https://github.com/yourusername/dontforgit-config.git ~/dontforgit-config
echo 'source ~/dontforgit-config/zshrc.sh' >> ~/.zshrc

1. Consistency Across Machines – If you work on multiple systems, maintaining consistency in your development environment becomes crucial. With a centralized configuration, you can replicate the same settings, commands, and functions across different environments. This ensures that you don’t have to worry about a missing command or alias when you switch from your workstation to a personal laptop.
2. Version Control for Configurations – Like any other codebase, shell configurations evolve. By putting them into source control, you gain access to all the benefits of version management. Need to rollback to a previous version? Easily done. Want to experiment with new features or environment changes without affecting your main setup? Create a new branch.With proper commit history, you also gain the ability to track what changes were made and why. For instance, I’ve tagged my configurations with descriptive messages like:
   • “Automatically switch node versions”
   • “Add helper scripts to streamline git commands”
   • “Add the sayresult success phrase”
   This provides context on what each iteration of your setup improves, just like you would document code changes.
3. Streamlined Sharing and Collaboration – If you work in a team, having a shared repository for configuration files enables you to standardize workflows. Colleagues can clone your configuration, suggest improvements via pull requests, or share their own enhancements. This means you aren’t just replicating setups—you’re actively collaborating to make a better development environment for everyone involved.
4. Portable Custom Scripts and Functions – One of the main reasons I committed my shell scripts to source control was that I had accumulated a variety of helper functions tailored to specific workflows. Whether it’s a simple gl alias for a pretty git log or a complex djbuild function for building specific projects, I no longer need to remember how to set them up again.For example, my auto_node_version script, which automatically switches Node.js versions based on the project’s .node-version or package.json file, is invaluable. Adding it to source control means I have it every time I set up a new environment, saving me from hunting down dependencies or rewriting the function from scratch.
5. Organization and Documentation – Having a README.md in your repository, much like any other project, acts as living documentation for your configuration. Anyone (including future-you) can reference it to see available commands, helper scripts, or the setup process. This makes onboarding onto a new machine or sharing configurations with others a breeze.My own README includes details like:
   • Available aliases and their descriptions.
   • Global NPM configuration helpers.
   • Git helpers like new, co, and con.
   • Environment-specific functions like djbuild for building Dow Jones plugins or ngbuild for NewsGrid workflows.
   This documentation approach turns a previously opaque, ad-hoc setup into a structured and understandable framework.

---

How to Get Started

If you’re convinced (and I hope you are), getting started is straightforward. Here’s a step-by-step approach to putting your configurations into source control:

1. Create a New Repository – Start by creating a new GitHub (or GitLab, BitBucket, etc.) repository, e.g., my-config.
2. Organize Your Configuration Files – Copy your .bashrc, .zshrc, and any other custom scripts into a folder structure. Consider creating separate files for aliases, functions, and environment-specific settings.
3. Document Your Setup – Include a README.md that outlines the purpose of each script, how to install it, and any dependencies.
4. Automate the Installation Process – Write a small setup script that automates the installation process. For example, automatically appending source ~/my-config/zshrc.sh to your .zshrc file if it’s not already there.
5. Commit and Push – Version-control your files, commit them with meaningful messages, and push them to your repository.

Conclusion

Putting your bash or zsh configuration into source control is more than just a convenience—it’s a long-term investment in your productivity. It makes your environment portable, shareable, and version-controlled, just like any other critical piece of code. The next time you get a new machine or need to replicate your environment, you’ll be glad you took the time to do this.

Take your development environment as seriously as you take your code. Because, in the end, your tools should work for you, not the other way around.