2

I'm using git post-receive hook to deploy versions of the web application from three branches (master, staging, and stable) on three servers (development, testing and production). The pairing between branches and servers is currently hard-coded in the script. However I'd like to remove this restriction and make this hook possible to manage unlimited quantity of branches. It can be done in the following way:

  • move all per-branch config options to some separate files, for example .git/???/<branch_name>
  • the main script will check if such file is available for every branch, source it and then deploy on the remote server using configuration parameters from that file.

However I don't know where exactly in .git directory can I place such files. Or maybe there is a better solution?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
jollyroger
  • 225
  • 1
  • 9

1 Answers1

2

Your options, as far as I can tell:

  • Use a stronger convention for server naming, so that config isn't necessary, beyond the base domain name. Leave that in the script. (That is, branchX -> branchX-deploy.example.com.)

  • Put a config file wherever you feel like in the .git directory, like you suggested. If it's not a filename git cares about, it'll never notice it. I'm not sure why you'd want to do this, though.

  • Put it in .git/config. Git lets you define arbitrary config parameters of the form branch.<name>.foo. (I have no idea if this is a feature or an oversight. It's not documented, as far as I know.) In your case, something like branch.master.deploy_server set to development.example.com. Your script could then just go through all branches, and check whether that config option is set or not. (Use git config --get.)

  • Put a config file in your repository. This seems a lot better than hiding it away. You might as well track the settings. If necessary, provide a way to override them - supply a different config file as an argument, supply individual branches/servers as options, interactive prompts, whatever suits you.

Personally, I'd probably do the last one. Tracking settings, even if they're only default settings, can't hurt you.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • I'd like to have at least username, hostname and target directory so only naming branches will not work. I also don't want to place such config in the source code tree since it has nothing to deal with sources and I don't want to bother developers with unnecessary knowledge. It seems I will be using `.git/config` since it is the most clean solution for now. – jollyroger Nov 12 '10 at 07:48
  • For the record, I completely disagree that .git/config is the most clean. It's untracked. – Cascabel Nov 12 '10 at 13:46
  • But It's really what I am looking for. This file shouldn't be tracked and available for a developer anyway since deployment is not a developer's (as a role) task. The responsibility of tracking the file lays on administrator and it's tools only. I've [implemented](https://github.com/jollyroger/vcs-hooks/tree/master/git/server-sync/) this solution, maybe it can be useful for someone except me. – jollyroger Dec 02 '10 at 13:46