What's your git workflow for your keymap(s)?
I'm starting to grow out of the default git workflow for QMK and wish to separate my keymap commits from core QMK commits.
In the documentation page on git best practices, you're told to create a new personal branch on top of qmk:master in your fork of the qmk_firmware repo. You commit your personal keymap files and changes in that commit and every so often, you rebase your commits on top of the HEAD of qmk:master.
It works fine until you want to use a pending core PR and/or contribute to QMK.
You have to juggle and keep up to date the PR commits that target qmk:develop as well as the qmk:master commits. You also have to plan ahead for the day when the PR gets merged into qmk:master. You wouldn't want duplicate commits in your git history (first the ones you merged while the PR was still open, and second the commits you merged when you rebased on top of qmk:master).
More annoying though is the case of contributing. Naturally, to work on feature, you first create a feature branch based on either qmk:master or qmk:develop (depending on what kind of contribution it is you want to make). You don't want your personal, irrelevant keymap commits to be included in the PR for your new feature so you don't bother copying your many keymap commits to the feature branch but then you have a problem if you want to actually test your new feature on your board.
Either you copy your keymap files into your feature branch temporarily or you copy your contribution commits into your personal branch. If you also happen to use another pending PR or two for your keymap, you'll also need to transfer those over.
To avoid that latter problem, you could have a keymap branch based only on qmk:master and another one on unmerged core PRs you're too impatient to use, but that entails having to maintain two keymap branches in sync.
Consequently, I was wondering what alternative git workflows would allow me to decouple my keymap from the QMK repo branch. So that I can do away with personal branches that have my keymap commits drowning in a sea of QMK commits and simply checkout an available QMK branch as is, without making any changes to it and have all my keymap files, commits, and history move along.
Posted Dec 17, 2020, 7:54 AM UTC
I use a separate qmk_keymaps repo for my own keymaps, and then I link the appropriate keymap folders into the qmk_firmware checkout.
Very simple compared to advanced git gymnastics.
This seems sensible.
If you don't track the keymap in the qmk_firmware git, then you don't have to worry about checking out different branches. (If the files are already committed in the index and you don't want the changes considered, there's ... a way to get git to ignore changes to tracked files, too).
Otherwise, get comfortable with interactive rebasing & resetting (if you want the commits shuffled around; or to go back and remove some commits later), or whatever. & make use of branches like
featureA+featureB.How exactly do you link them? A symlink to your
qmk_keymapsthat you ignore in the .gitignore of yourqmk_firmwarefolder?Just a symlink, yes. I don’t bother with gitignores.