Git Dotfile Branching
Working with multiple computers, like a work and a personal laptop, often involves differences in operating permissions, applications, systems, … For example:
- While symbolic linking of files is allowed on Linux, not so on the administered Windows work machine.
- Some software might work fine on Ubuntu but not so on OpenSUSE, for example, by different versions of dependent libraries, like
glibc. - Work and personal laptop use different directories for storing documents, requiring conditional configurations.
To manage these differences, maintain separate Git branches for each machine’s specific configurations. My current strategy builds onto Greogry Anders’ blog post:
Centralization
Maintain as many common dotfiles as possible in the main branch (formerly master); ensuring that any universal changes benefit all setups.
Adding a folder for tools predominantly used on one machine but less on others does little harm, but removes friction.
For example, the Zsh and Bash profile, as well as Autohotkey scripts (for setting up key combos in Windows, among others), can be all kept in the main branch.
Change Management by Rebasing Commits on top of the Main Branch
Commits on branches other than the master branch are always kept on top of those of the master branch, ensured by git rebase --onto (as is common practice for a long running side branch):
-
When you need to integrate updates from the
mainbranch into a side branch likework, use the commandgit rebase --onto main HEAD~123where123is the number of commits sinceworkdiverged frommain. This command rewrites the history of theworkbranch to include the latest changes frommainwithout duplicating commits. -
Conversely, if changes were made directly to the side branch
workand need to be reflected in themainbranch, then usegit branch --force main HEAD~123where123again designates the number of commits sinceworkdiverged frommain.
In essence, that summarizes the process.
To replicate your changes of a branch, say work, onto different computers
- pull them with
git pull --force origin work:work, and - push them with
git push --forward-with-lease origin work:work.