Unofficial guide to dotfiles on GitHub (dotfiles.github.io)

I use this script (which I modified a bit from the Atlassian one) to bootstrap it on a new $HOME dir (replace "***YOUR_GIT_REPO_ADDRESS***" with your address; also, you need to copy the function ,cfg into your .*rc file for command-line use):

    #!/bin/bash
    set -euo pipefail # the usual stuff

    # TODO: copy the below function into your .*rc file
    function ,cfg {
        /usr/bin/git --git-dir="$HOME/.cfg/" --work-tree="$HOME" "$@"
    }

    # TODO: replace '***YOUR_GIT_REPO_ADDRESS***' below
    git clone --bare git@***YOUR_GIT_REPO_ADDRESS***/.cfg "$HOME/.cfg"
    ,cfg config status.showUntrackedFiles no

    if ,cfg checkout; then
        # worked fine, we're done
        echo "Checked out config."
    else
        # it failed, so assume we need to move some files out of the way
        echo "Backing up pre-existing dot files."
        mkdir -p "$HOME/.config-backup"
        ,cfg checkout 2>&1 | grep -e "\s+\." | awk "{'print $1'}" | xargs -I{} mv {} "$HOME/.config-backup"/{}
        ,cfg checkout || (echo "Still cannot checkout configs; see messages and fix." && exit 1)
        echo "Checked out config."
    fi

    ctm = commit -a -u -m           #commit all tracked files with message

    ,cfg ctm "I modified my .zshrc"
    ,cfg push*

To avoid that, one can rename the `.git` folder, effectively disabling auto-discovery, and run git with the option `--git-dir=<newname>`.

The only issue I've had with this approach is that new files which I'd like to commit to the repository are ignored by default. One could use the .gitignore negation strategy like OP mentions to first unignore the file and then add it to the repository. I just end up using git add -f foo to force the addition even though foo is ignored.

I keep a second copy repo on a thumb drive so I can start my home directory on an offline computer.

    # .dotfiles/.bashrc
    # shared baseline config...
    if [ -f ~/.bashrc.local ]; then
        . ~/.bashrc.local
    fi

I do this by having ~/.config/tool/blah.conf as you'd expect; but also ~/.config/by-host/$hostname/tool/blah.conf

I agree 'classes of hosts' is way overkill for probably anyone's personal machines though. Only thing close to that I do is with aconfmgr for more system-oriented stuff - but that's all simply on the basis 'if SSD enable TRIM' type 'classes', no manual specification.

Not everyone has the time to create their own custom dotfiles.

Some just want sane and beautiful terminal defaults.

What I do with RasPi servers is I make a pull and a push playbook that live in a repo, which let me deploy what I have onto a new server, and pull any changes made in server web GUIs into the repo where I can commit them.

Then of course any other random periodic task also becomes an Ansible task.

If I had a use case for lots of random little scripts on my main machine, I think I'd choose Ansible over bash where practical, you get so many tools premade, and you can run local or remote all the same.

The big benefit is that it can be organized in a modular way with roles and tags, and sensitives files (like my gpg keys...) can be encrypted with the vault.

I use it in combination with a make to automate the setup of a new install.

One thing, I didn't split things by apps per se. I split them based on task. In some machines, I do Python work, so I created a 'python' package. In some I do PHP, so I created a 'php' one. I have a 'base' one where it has my .bashrc, .profile, .bash_profile, fish configs and other things.

Everything in the .bashrc. .profile, etc is loaded around conditionals. So, while the files are long, the section only activates if the other package is available. I thought about splitting it onto files, but most editors have a way of collapsing sections, so I decided to keep it on one so it's easy to edit in one place.