wingyip
wingyip

Reputation: 3536

Only push some changes to remote

I am working on a codebase locally where I have had to make a large number of config changes to get things to run on my local machine.

Basically I am fixing bits and pieces of this app and uploading fixes to remote branches where they are reviewed and pushed to the main dev branch.

I need my config changes locally for the app to run but do not want to include them in any pushes to remote branches.

Is there a good way that I can save my config changes locally (maybe in a local branch) but not upload them when pushing other fixes?

Upvotes: 0

Views: 42

Answers (3)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

There are multiple strategies to handling environment-specific parameters. The best solutions involve modifying the build process so that "local" config files aren't stored in source control.

For example, you could store a template for the config file and have your build process read a property file to determine the final values to be interpolated into the template. The values for shared environments (prod, qa, dev) could be stored on the build server and/or in source control separately from the template. Your local values would be in a property file you maintain, though a "default" file for that purpose could certainly be kept in source control (with the intent that you copy and modify it, to avoid accidentally posting your local changes to the default file).

If you can't get that sort of change implemented? Well, people are forever coming up with solutions based on stash, or modified flags in the index (skip-worktree, assume-unchanged). I generally recommend against these as they all have shortcomings to the degree that they "might work sometimes". But in the absence of being able to make this a build problem, that may be the best you can do.

Upvotes: 2

Tim Biegeleisen
Tim Biegeleisen

Reputation: 522712

git stash might work well here. In a given branch, you could make the configuration changes to the necessary files, do your testing, and then git stash your work. This would wipe your working directory and stage, but later you could apply the stash whenever you wanted to bring back those configuration changes.

You would probably want to name the stash, so you can easily refer to it later on:

git stash save "testing configuration"
git stash apply stash^{/testing}

This approach would not work well if you expect the code involved in the configuration to change dramatically over time. In that case, applying your stash would either generate many conflicts, or just wouldn't leave you with usable code. You could partially mitigate this problem by refreshing the stash each time you apply it.

Upvotes: 1

Ian McInerney
Ian McInerney

Reputation: 31

You can either just commit changes to the files you modify. Or you can use the .gitignore file: https://help.github.com/articles/ignoring-files/

Upvotes: -1

Related Questions