Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Getting git to never push a single commit?

Tags:

git

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
like image 300
Nobody Avatar asked Aug 29 '11 19:08

Nobody


People also ask

Can you git commit without pushing?

So commiting changes without pushing allow the save-load behaviour done locally during development. Once you are happy with your work, you then commit AND push.

Do I need to push every commit?

Typically pushing and pulling a few times a day is sufficient. Like @earlonrails said, more frequent pushes means less likelihood of conflicting changes but typically it isn't that big a deal. Think of it this way, by committing to your local repository you are basically saying "I trust this code. It is complete.

How do I push only selected commits?

If the commits you want to push are non-consecutive, simply re-order them with a git rebase -i before the specific push. @MarkVY Updated to make explicit both remote reposity and remote branch.


1 Answers

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.

like image 91
Karl Bielefeldt Avatar answered Nov 15 '22 23:11

Karl Bielefeldt