There are always some changes that you make temporarily but must never make it upstream, such as development-specific debugging instrumentation. The trick is to keep track of these but never send them upstream (to a repository you share with others, for instance).
Unsuprisingly, git’s got a way to handle this. Thank you, Karl Bielefeldt!
master is the upstream integration branch…
# just once: create branch for dev-only changes git checkout -b common-dev-changes # get latest upstream changes git fetch # rewind/replay common-dev-changes on top of master git rebase origin/master # switch to topic branch for a new feature/bugfix git checkout -b topic-branch common-dev-changes # ...edit files, debug, commit, etc... # prepare to push - remove dev-only changes git rebase --onto master common-dev-changes topic-branch # switch back to master git checkout master # merge feature/bugfix code into master git merge --ff-only topic-branch # ...do integration testing... # share your work! git push
I’ve been jumping through all sorts of hoops like always having locally-modified files,
git stash, even keeping patch files around. These techniques quickly become unwieldy with larger sets of changes because you forget why you authored a change or you accidentally push it upstream.
rebase --onto was hiding in git-rebase(1) all this time, but I just discovered it today thanks to Google and stackoverflow.
If you don’t want the technique I outlined above another answer on that same stackoverflow post outlines using the git index (
git add -p and friends) for managing your dev-only changes. That might be a handy stepping stone, and will provide tools you’ll still need later even when you are savvy with branching and