Question

I don’t think this is possible, but thought someone might have a nifty idea of how to accomplish this:

I have a project that I checked out that was in existence long before I took it over. I have about a dozen changes in various files that I never want checked in (they’re all config changes).

Is there any way to commit this set of changes and then never actually push that one commit? I know it sounds odd 🙂

clarification:

I want these changes to stay in my working directory, I need them for the app to function locally. I want to be able to keep commit other changes around them, even changes in the same file, but never push the config changes to anywhere else…

It’s somewhat like before every push I would want to:

• cherry pick and stash this one commit
• rebase the one commit out
• push
• re-apply this stash to my codebase

Answer 1

This is a similar pattern to maintaining a local patch set to an upstream project you don’t control. The easiest way to handle this is to have an intermediate branch that all changes get merged through, like this:

___________________________ master
\__________________________ config-changes
     \_____________________ daily-work

master contains everything that is to be shared. The only things committed in config-changes are changes you want to be able to revert easily when they are shared. daily-work is the branch you do all your work in. To set it up, do:

# (no local config changes should be in master at this point)
git checkout -b config-changes master
# Make your config-related changes that you don't want to share
git commit -am "Made local config changes"
git checkout -b daily-work
# Work and commit like normal

When you’re ready to share your changes, do:

git rebase --onto master config-changes daily-work
git checkout master
git merge daily-work

That will revert all the changes made in config-changes, but otherwise make it look like you branched directly from master. Note that after you do this rebase, if you want to continue to work in daily-work, you need to rebase it back onto config-changes, but it’s really better to create a new branch for each change.

When you need to pull down new changes from master, do:

git checkout master
git pull
git checkout config-changes
git merge master

The merge reapplies your local config changes onto the latest master. You’re then free to create a new daily-work branch, or merge config-changes into the old one, as appropriate. Basically, you never merge directly from master into daily-work. You always go through config-changes first.

It seems like a lot of work at first, but once you do it once or twice you’ll see it’s a lot easier than maintaining the changes manually.