Question

Switching to GitHub and can’t seem to find information on how to do something I used to do with SVN:

First of al I’m a tester so I never commit changes, but I do need to keep a number of local copies of the project each with a small difference to trunk – staging, production, decreased timer values etc

I used to use CornerStone on Mac (just fwiw/don’t have it any more), and a single update from SVN would update all my various local ‘dependent projects’ (all of them the same, apart from one or two lines, usually in a config file). I’d review the inevitable conflicts and almost always reject them, provided the only difference in the conflicting file was my customisation for test purposes, or if there was something new I’d merge it in and leave my staging environment URLs or whatever as they were.

Can I do this sort of thing efficiently with GitHub? (preferably using GitHub’s/Xcode’s or some other Mac GUI client?)

I did look at the documentation, but can’t seem to find anything on this so any help much appreciated/maybe it’s kind of unusual to be pulling changes to lots of almost-identical local projects and always be rejecting certain conflicts.. 🙂

Answer 1

Of course, the ideal solution is to not have configuration data tracked in the repository, or at least make it possible to override via some untracked file.

However, there’s no problem with what you want to do in git. You just locally make multiple clones of your GitHub repository. In each, you can make your changes specific to that local copy, and then commit them. Then, when you want to update from the latest version of GitHub, make sure that you pull with:

git pull --rebase

… which will fetch the latest version from the server, and then try to reapply your commits with local changes on top of them. Unless the same parts of the files that you’ve committed changes to have also been modified in the new commits on GitHub, you shouldn’t even have conflicts to resolve.

If you always pull like this, then the commit graph (history) of your project will always be the same as the remote, but with any of your local changes as the most recent commits on top of the remote history.

(I would hope that the GUI clients that you are using have an option to rebase on pulling new changes. Otherwise you can set this to happen automatically with the config option branch.<name>.rebase, where <name> is the name of your local branch.)