Here's the scenario. I made a "dev" branch off the "master" branch and made a few new commits. Some of those changes are going to only be relevant to my local development machine. For example I changed a URL variable to point to a local apache server instead of the real URL that's posted online (I did this for speed during the testing phase). Now I'd like to incorporate my changes from the dev branch into the master branch but NOT those changes which only make sense in my local environment.
I'd envisioned something like a merge --patch which would allow me to choose the changes I want to merge line by line.
Alternatively maybe I could checkout the "master" branch, but keep the files in my working directory as they were in the "dev" branch, then do a git add --patch. Would that work?
One approach would be to merge the changes from the other branch, but remove the development-specific content before committing the merge.
First, get the changes, without committing them with git merge --no-ff --no-commit dev
.
Remove the development-specific changes either by editing the affected files and git add
ing them, or git reset HEAD
the affected files and then git add --patch
the parts you want.
Then commit the merge. An advantage of doing a merge commit is that future merges will be painless. Because the development-specific commits are considered merged, future merges not involving development-specific pieces can be done with a simple git merge dev
. In this way you can indefinitely maintain a separate branch with its own configuration while still painlessly merging changes into the master branch.
Maybe you could try something like this?
git merge --squash --no-commit $YOUR_OTHER_BRANCH
git reset HEAD
git add -p
git commit