-2

A question on how to practically use Git.

I have code that's deployed onto 2 servers (1 for staging, 1 for production); it's the same code but for a couple of files (different paths in config files).

NOTE -- I generally commit/push from a dev laptop, and just pull from those 2 servers.

I want the Git master branch to be an exact copy of the production fileset as it is running now. I think it makes more sense -- does it?

Though, I don't know exactly where to put the diffs for the staging server:

  • Is it better to use a staging branch? But, then, I must think to remerge every time I make a change into the master branch.

  • Is it better to commit locally, on the staging server, the path changes, and let Git rebase those commits (on top of HEAD) every time? But, then, I have unpushed commits staying there -- it can become a little mess, and I don't have to push them by mistake...

Is there another, simpler, scenario which I don't think of?

user3341592
  • 1,419
  • 1
  • 17
  • 36
  • It is not entirely clear what you are asking. – Shaun Luttin Jan 29 '17 at 20:21
  • Files are 99% identical in both env (stg, prd). What do I do for the 1% diffs? Put the version for the stg environment onto another branch? Put it as a commit that's kept locally on the stg server (and will be rebased every time I pull new changes from the repo)? Or better use another "model"? – user3341592 Jan 29 '17 at 20:53
  • Is this more clear now? – user3341592 Jan 29 '17 at 20:53
  • Hmm. There are a bunch of ways to handle this and I'm afraid there is no "right" answer. The question has a primarily opinion-based answer. Consider changing the question to one that has a verifiable correct answer. I do feel your pain here, because I've faced similar decisions. – Shaun Luttin Jan 29 '17 at 21:02
  • 1
    Of course, mileages may vary here; but I've listed what I see as pros and cons from my current knowledge. What I'm after is hints from experimented Git users about a better way to handle this. And I couldn't find this in the Git references I read. That said, I don't see how I could change my question, as I'm in a way searching for something I don't know yet (a better solution, with less cons). – user3341592 Jan 30 '17 at 12:14
  • This sound like a duplicate of : http://stackoverflow.com/questions/9636492/branching-different-config-files-for-release-development – Destrif Jan 31 '17 at 19:53
  • @Destrif -- It'd make sense you'd receive the bonus. Do you want to publish an answer of your own? Best regards. – user3341592 Feb 01 '17 at 20:09

2 Answers2

2

You should use a environment variable for this. You can define an environment variable to choose between staging and production. If it's not defined you can default to production.

Your config file can read through the environment variable and choose the correct configuration for staging or production environment.

This way git can always point to Master with production as default and staging server will have staging specific configuration.

From git perspective I don't think we can checkout a master to do 2 different things. Creating branches and merging them is also a pain so best way to manage this would be to use a environmental variable

manishg
  • 9,520
  • 1
  • 16
  • 19
  • Do I understand correctly you're speaking of shell env variables, for example? Because my diffs do concern more than that: as well paths or some little functionality in ASP pages, and README documents... So I can't summarize everything as a condition depending on the hostname. – user3341592 Feb 01 '17 at 07:19
  • I think the comment given by @destrif makes sense then. http://stackoverflow.com/questions/9636492/branching-different-config-files-for-release-development . You can add .gitattributes and a smudge filter as described in that link – manishg Feb 01 '17 at 14:18
  • Yes, that seems a better way to handle this. Totally unknown to me. Glad I've been learning something new, once again... – user3341592 Feb 01 '17 at 20:10
0

It is best to manage those config files as separate files:

  • myconfig.master
  • myconfig.dev
  • ...

Then, as I described in "Ignore files when merging branches", you can declare a content filter driver (using a .gitattributes declaration) which would, on checkout automatically copy the right file as myconfig.
The actual myconfig generated file would remain ignored and private.

smudge

Your smudge script can determine the name of the checked out branch with:

branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250