I have a bunch of bash scripts loaded from my .bashrc that I store in a private github repo so I can use them across computers. Each computer has its own quirks, so I have a branch for each one. I started this project on my work computer, so master has a bunch of code that's not relevant for my home environments.
In those branches, I've deleted the work-related changes, however it would be much better if I could make work its own branch and make master a base, non-customized set of code. That way, whenever I make a change in my work branch, I don't get merge conflicts about deleted files when I rebase my home computers onto master. However, I want to make changes to master that apply to all of my branches; if I then rebase work back onto master--which has deleted my work code--work will receive those deletions.
How can I branch master into work, delete the work-related changes on master, and then rebase work back onto my cleaned master without deleting all the work-related code in work?
I could use git rebase --interactive and split out all of my work changes since the beginning of time, but that seems tedious for an action that can't be all that uncommon.
I saw git rebase --onto and git filter-branch but from what I read, neither of those look like the right approach.
How can I branch master into work, delete the work-related changes on master, and then rebase work back onto my cleaned master without deleting all the work-related code in work?
A rebase onto master would use a... rebase --onto:
git rebase --onto master $(git merge-base master work) work
That would replay your commits from work on top of the cleaned master
git merge-base master work
|
m--m--m--M (master, cleaned-up)
\
w--w--w (work)
git rebase --onto master $(git merge-base master work) work
m--m--m--M (master, cleaned-up)
\
w'--w'--w' (work, rebased)