I’ve been using git for the past several months hacking away on a new project by myself for the most part, but a couple days ago I decided to branch to maintain a production, test, and dev version of the code base not to mention versions for different platforms. It reminded me of how at my old job everyone had their config settings in the same file, but they were using subversion.
It always seemed like an error prone way to maintain everyone’s settings. If someone inadvertently updated the file and you pulled the latest changes, you’d have to update your settings or hide them, and pulling changes was a hassle.
So I was thinking about how to keep configuration file changes private in different branches of my project. Luckily Yaakov Nemoy had already written a piece on it. Keeping Private config files Private in Git
Awesome. I wasn’t really familiar with git rebase, so the tutorial was a concrete example of how to use rebase compared to the man page.
But the after going through it, with my own project, I have to echo the sentiment in the comment by Peter Zei. So I decided to checkout Stacked Git which is pretty cool!
So below is a workflow on how to use Stacked Git, stg, to manage changes between your branches. You should already be familiar with git commands before diving in since some of the stg commands have the same names but different behavior than the git commands.
mkdir stg cd stg git init vi README # insert "init" git add README git commit -m "init" # We've intialized the repo, now let's add our config file. vi config # insert 'production' git add config git commit -m # Now let's branch for a development version stg branch -c dev # equivalent to : git checkout -b dev ; stg init # we need to initialize every git branch for use with stg # Let's create a new patch stg new conf # enter message: dev config settings stg series # shows us our uncommitted patches # Now modify the config file vi config # replace production with development stg status # shows that we modified config stg refresh # updates our patch stg show # shows our changes # Now let's create a new patch, add a file to it and get it back # into master without sending along our config changes. stg new add_code # message: adding some code vi Main.as # some code stg add Main.as # or: git add Main.as stg refresh # this completes our patch stg series # this shows our two applied patches + conf > add_code # Before committing we want to pop our conf patch stg pop conf stg commit # this turns our add_code stg patch back into a git patch and commits stg push # pushes conf back on the stg stack # We'll switch back to our master branch and merge the dev changes stg branch master git merge dev git log -1 # shows the new patch
And there you go. Managing your config files is just a matter of popping and pushing a patch with Stacked Git. If you forget to pop before committing you can run an uncommit for the patches through conf, pop conf, and commit.
stg series # blank from previous commit git log # shows conf changes are 3 patches away stg uncommit -n 3 stg series # returns + dev-config + added-x > addedY stg pop dev-config stg commit stg push # Notice that the patch names for conf was changed. Let's rename it stg rename dev-config conf stg series + conf
Here are more links to get you started.