3

I use Git to deploy my projects in my production system. The procedure I follow is:

  • First time I clone the repository, make changes in the config file (different in any production server) and then create a branch called "pro" that keeps these changes. Production server is always working in "pro" branch.

  • Then, when there are changes and I want to update my server I execute a batch file that makes this (more or less):

    git checkout master
git pull
git checkout pro
git rebase master

I'm sure that git has a easier way to do this, but I don't know how (perhaps it's possible to update one branch from another). Is just for curiosity and learn more about Git.

Mat
  • 188,820
  • 38
  • 367
  • 383
Ivan
  • 12,309
  • 13
  • 55
  • 89

2 Answers2

4

I would recommend a different method as it isn't generic to all environements (dev, UAT, prod, ...).

Why not using a content filter with:

  • a versioned template config file
  • several config values (included a 'prod_values' file)
  • a version script (called the 'smudge' script) able to recognize its execution environment (prod or not prod) and generated the right (unversioned) final config file

content filter driver

You would push to a bare repo with a post-receive hook checkout'ing your project in the right production directory.

Since this project has a content filter declared in it, the smudge script will automatically (on checkout) create the right config file.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Just a small note - OP's procedure isn't rewriting `master`, just `pro`, which probably doesn't matter assuming that it's not public. – Mark Longair Oct 22 '11 at 09:59
  • @Mark: right, I have fixed the main reason for using content filter. – VonC Oct 22 '11 at 10:13
2

Should work (on pro)

git fetch --all
git rebase origin/master

However, I don't see any problem with a 4-liner ;)

KingCrunch
  • 119,075
  • 18
  • 142
  • 167