Keep a commit locally to clone in Git

Question

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?

Answer 1

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?

Answer 2

How about creating a branch to contain your local changes ?

Answer 3

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.)

1. 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, pull on the remote client and run another git revert to redo the client-only change. Don't push from the client ever again. You can continue to update the client with git pull --rebase to avoid a growing trail of redundant merge commits

2. 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~:master to push everything but the local (now last) commit

Answer 4

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.}