Building a GitHub-Based Bash Alias Library

I use a lot of Linux systems in my homelab, and after a while I started collecting more and more Bash aliases.

The problem?

Every time I set up a new server, I had to remember which aliases I had, copy my .bashrc, or manually recreate everything.

So I decided to build something a little more convenient: a centralized Bash alias library hosted on GitHub.

The idea is simple:

Keep my aliases in one GitHub repository and let an installation script automatically discover and install them.

The Basic Idea

Instead of putting every alias directly inside .bashrc, I keep them organized in my GitHub repository.

For example:

aliases/
├── docker.bash
├── linux.bash
├── network.bash
├── proxmox.bash
└── system.bash

Each file contains aliases related to a particular topic.

The installer downloads the repository, discovers the available alias files, and makes them available to the current user.

That means when I add a new alias to GitHub, I don’t have to manually modify .bashrc on every machine.

Why Do This?

There are a few advantages to this approach.

One Place to Maintain Everything

Instead of having slightly different .bashrc files across multiple servers, my aliases live in one repository.

Easy to Deploy

When I install a new Debian or Ubuntu server, I can simply run the installer and get my usual command shortcuts.

Easy to Update

If I add or change an alias, I can update the repository and pull the changes onto my other systems.

Organized

Rather than having a .bashrc containing hundreds of aliases, I can separate them into logical files.

A Few Example Aliases

I don’t need hundreds of aliases to demonstrate the idea. Even a few simple ones make the concept useful.

For example, some Docker shortcuts:

alias dps='docker ps'
alias dpa='docker ps -a'
alias dcu='docker compose up -d'
alias dcd='docker compose down'

Some useful Linux shortcuts:

alias ll='ls -lah'
alias ..='cd ..'
alias c='clear'

And some system-related shortcuts:

alias update='sudo apt update && sudo apt upgrade'
alias ports='sudo ss -tulpn'

The important part isn’t the aliases themselves.

It’s where they are stored and how they get installed.

Automatic Alias Discovery

One of the things I wanted was to avoid hard-coding every alias file into the installation script.

Instead, the installer looks at the repository and discovers the available files automatically.

So if I add:

aliases/network.bash

later, the installer can find it without me having to modify the installer itself.

This also makes the repository easier to maintain.

I can simply create another .bash file whenever I want to add a new category.

The `.bashrc` Integration

The installer doesn’t need to replace the user’s entire .bashrc.

Instead, it adds a small section that loads the alias library.

Conceptually, it looks something like this:

# My GitHub Bash Aliases
for file in ~/.bash_aliases/*.bash; do
    [ -f "$file" ] && source "$file"
done

This keeps the actual aliases separate from the main Bash configuration.

It also means I can continue using my normal .bashrc without worrying about losing existing settings.

Adding a New Alias

Once everything is set up, adding a new alias is simple.

I create or modify one of the files in the repository:

aliases/docker.bash

Add the alias:

alias dlogs='docker logs -f'

Commit and push the change to GitHub.

Then I can update the alias library on another machine.

No copying and pasting between servers.

The Installer

The other part of the project is a small installation script.

Its job is basically:

Check that the alias repository is available.
Download or clone the repository.
Find the aliases/*.bash files.
Install them for the current user.
Add the required .bashrc section.
Reload the Bash configuration.

The goal is to make installing my personal Linux environment almost as easy as installing a package.

Keeping It Simple

I deliberately didn’t want to turn this into a huge configuration-management project.

For my homelab, I wanted something lightweight.

GitHub handles the version control.

Bash handles loading the aliases.

The installer handles deployment.

That’s really all I need.

What’s Next?

This could easily be expanded later.