Git - Pushing to a production website

Hi,

Our company's website is stored in a GIT Repository.

The repository is coded for our test server. When we push updates to the production server, have manually run a script to patch several files to make the code work on the production server (i.e. port numbers, etc).

I'd like to write a script to email me whenever someone changes files on the production server without checking those changes back into git (i.e. running 'git status | grep "nothing to commit" ...').

However, this approach get confused by the files patched to work correctly.

Is there any way to 'save' those patched files so they don't get reported by 'git status', yet not mung up the git history every time we push out an update?

Thanks!

On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:

Interesting.  I like the thought.

You could simply commit after running the perl script. You could even commit to a branch so that it's (a little) less likely those changes get integrated into master.

How about this, ran by the post-update hook:

For the first update:

 - Do a git pull
 - Then create a new branch 'working' and checkout
 - Apply the patches to 'working' and commit

This leaves 'working' == 'master^'

For subsequent updates:
 - Compare the SHA1 hashes for 'working' and 'master^'.
   - If they don't match, throw an error and exit
 - Assuming they match, checkout 'master' and delete 'working'
 - Do a git pull
 - Then create a new branch 'working' and checkout
 - Apply the patches to 'working' and commit

This would keep the working directory clean and allow future updates to occur, if no one commits anything to git 'working'. If they did, the script would exit and prevent the update requiring the developer to review the commit logs and cherry-pick where necessary.

On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@dyweni.com wrote:

I'm not enitirely sure you want post-update doing the pull.

Actually, it leaves HEAD == working and master == working^.

(See above)

It wouldn't *completely* prevent changes to working as one could "git commit --amend" and still have working^ == master. That said, if developers get creative enough they can probably bypass most measures, at least those based on a hook.

A privileged process for updates could stash the expected SHA for master and working somewhere developers can't write. That should prevent even dedicated developers from making unauthorized changes, modulo security/cryptographic exploits.

Really?

Let's say the website lives in /srv/www/htdocs Let's also say the git repository lives in /srv/www/git

All developers pull/push from /srv/www/git  (git@server:/srv/www/git)

The website is a clone of /srv/www/git and only tracks 'master'. Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.

I'm referencing this article:
  http://jblevins.org/log/tools/managing-websites-with-git

Would you recommend a different way to automatically push any changes to 'master' down to the website?

I'm sorry - I mixed up my terminology.

I am referring to the branch's log.

'working' has 1 more log entry than 'master'.

Example:
 - git log master | grep ^commit | tail -n 2 | head -n 1
 - git log working | grep ^commit | tail -n 1 | head -n 1

Both of these commands should return the same commit hash.

On Friday 09 January 2009, 4jxDQ6FQee2H@dyweni.com wrote about 'Re: Git - Pushing to a production website':

Ah. I was assuming you were "git pull"ing in the repository that the hook was running from. In this case you are "git pull"ing in a different repository, which should be fine.

Yes, which means working^ == master.

commit-ish^ means the first parent of commit-ish commit-ish^2 means the second parent of commit-ish commit-ish~2 means the "first grandparent" of commit-ish

As would:
- git rev-parse master
- git rev-parse working^

On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote:

one nice thing about git commit is that if there are no changes it doesn't make a commit.

I have a couple files on my desktop (firefox status files for example) that I have a cron job do a commit on every min so that when firefox crashes in a way that can't be recovered by it's 'restore old pages' option I can go back and save things anyway.

David Lang

On Fri, Jan 9, 2009 at 20:23,  <4jxDQ6FQee2H@dyweni.com> wrote:

Are these all static pages? If they're Perl/PHP/Ruby/whatever, why not add tests for the Live vs. Dev? Check for an environment variable, or a file on disk, etc, etc? That way any checks described below won't get "confused" by the (no longer necessary) patches, and you won't have to worry about rebasing commits, and any potential conflicts there.

On Fri, Jan 9, 2009 at 8:23 PM,  <4jxDQ6FQee2H@dyweni.com> wrote:

The simplest solution is to not track those files at all. Instead of tracking app.conf, mv it to app.conf.sample and track that instead. Likewise, add an entry for app.conf in .gitignore.

When devs create new sandboxes they just
        cp app.conf.sample app.conf
and all is well because app.conf is in .gitignore.

If you literally do 'git mv' in a sandbox and push it out then be careful since pushing that change to production will do exactly what it was told to do (remove the config). it's a small price to pay for simplicity, though, so just remember to keep a backup.

Having the config files in .gitignore eliminates a lot of work in your update hooks and it makes writing this script much easier.

The only extra cost comes in having to manage the config files separately from the application, but it's nothing that can't be automated.

On 2009-01-10, <4jxDQ6FQee2H@dyweni.com> <4jxDQ6FQee2H@dyweni.com> wrote:

Shouldn't they change it in a sandbox and push it to prod when it gets done instead of directly changing on prod?

If you can enforce no changes directly to prod, you can have the prod server's "master" branch be the one that QA or whatever pushes to (no direct changes on prod).

You'd manually (one-time) create a branch called prod_patches where you'd make just the changes needed (port numbers etc as you said).

This would be the "checked out" branch.

On each push to master, a hook would just "cd wherever; git rebase master"; the port changes would carry over.