Keep a commit locally to clone in Git
I have two repositories. I started a project locally on my development machine, later cloned it to a testing environment on the customers server. I mimic the environment on the customers server, but for that I need to have some files (and some lines in some other files) to be only present on my local machine, but they must not appear on the remote environment.
I’ve deleted these files and lines just after I cloned the project and committed these changes on a single commit in the remote repository, but after a push (back to the origin repository) I would have to ignore this commit on my local repository. I would like to have both repositories in sync, except for this single commit, so the project would
run on both, slightly different, environments.
How would I do that? How can I ignore a commit locally without altering it on the remote repo after a push/pull?
4 Solutions collect form web for “Keep a commit locally to clone in Git”
The simple answer is not to keep anything machine-specific in version control, or at least to keep machine-specific commits in files which are copies or templates of the file actually being used by the application.
See: Is there a way to make TortoiseSVN temporarily ignore versioned files?
How about creating a branch to contain your local changes ?
As @ben-james answered, leave the file out of git if you can. If not, there are two solutions, depending on your development model. (The 2nd solution can be generalized to any development team with custom commits for each dev.)
If you always commit code on your local machine AND the client always pulls, but never commits or pushes: Assuming that the change has already been committed, revert the commit on your local machine with
git revert. Then,
pullon the remote client and run another
git revertto redo the client-only change. Don’t push from the client ever again. You can continue to update the client with
git pull --rebaseto avoid a growing trail of redundant merge commits
If you need to commit code on your local machine AND you need to commit code on the remote client: There’s an easy but annoying way to do this. You can keep you commit local by rebasing every time you push/pull.
- Pull with
git pull --rebase
- Before pushing, use git
rebase -i <LOCAL_COMMIT>to re-order the local commit as the most recent commit
- Push with
git push origin master~:masterto push everything but the local (now last) commit
- Pull with
Usually, for config files, you keep in the repo a template config file, along with a script able to generate a “private” (i.e. not versioned) config file with the right values depending on the current environment/platform.
That way, you do not have to deal with any “conditional” commit.
See also the SO question “How to track config files of submodules in Git?”
Note: I realize you are not necessarily talking about config file per se, but that still can give you an idea about how to manage similar files.