How to release with Git?

views:

127

answers:

+4 Q:

How to release with Git?

I have a basic question about Git:

Let's say there is subdomain git.mysite.com with git installed in it. My actual site is on mysite.com. How do I tell Git to "release" a specific or latest commit to mysite.com?

I use MediaTemple(gs) for my hosting. Site is in /domains/mysite.com/html and Git is in /domains/git.mysite.com/html/mysite.git .

Thank you!

+2 A:

You would need to run a git pull from the site managing git. I'm not sure how MediaTemple handles that, or their file / site structure.

Josh K 2010-08-09 20:06:27

I think that I would have a cron job that runs git remote udpate && git checkout remote/branch. pull has too many things that can go wrong because it merges.

xenoterracide 2010-08-09 20:18:05

@xeno: Pull will have no issues as long as the working copy (i.e. the one on the server) hadn't changed. You will have merge conflicts if something major does change. I also wouldn't recommend cronning this because you could have an occasion where you're making changes and comitting / pushing, yet don't want those changes live. Pull manually from the server.

Josh K 2010-08-09 20:24:21

'as long as' and don't work in the branch that's being checked out. get a sane workflow.

xenoterracide 2010-08-09 22:18:19

personally I don't like working under the assumption that someone hasn't done something stupid. pull can cause problems if you aren't doing a manual intervention, I've seen it with thinks like PKGBUILDs and ebuilds and had to rewrite them to use code that was less vulnerable to upstream changing stuff. As far as cron-ing if you have production branch... and you only push stuff into it that's ready you should be fine. of course you can do it manually if that's what you want to do.

xenoterracide 2010-08-09 22:22:49

@xeno: You would rather assume that they will always remember to push to the right branch rather then they pulled from the wrong one? I have **never** been in a production environment were the production server was cronned to pull from versioning. That is stupid.

Josh K 2010-08-09 22:47:01

when you pull it's not just about which branch is being pulled from.... but what it's being pulled into.... if someone changes what branch is checked out... it also depends on the fact that no one did a rebase or a reset. checkout however just works (unless you go and throw stuff in the working directory). Yes I expect people to be smart enough not to push to the 'production repo/branch', in fact I expect the level of intelligence that says only 1 person has write to that repo that the server(s) updates from anyways.

xenoterracide 2010-08-09 23:13:02

@xeno: So now you have multiple repositories? **Why not take the simple route?** The production server shouldn't need to be continuously updated anyways. You have a production "release" that has been run through Dev, Q/A and client approval, you "push" that to prod by logging in and pulling, taking care of any issues at the same time. Then you **leave it alone**. Production is not a nightly build. It is a release snapshot.

Josh K 2010-08-10 04:06:56

you have multiple repositories (or you could just have a branch) given the right workflow. because you have dev server, staging servers, and production servers. TBH just having a branch isn't all that hard. Doing it by hand just doesn't scale if you have > 3 servers.

xenoterracide 2010-08-10 16:16:09

@xeno: You have obviously never managed more then 3 servers, and you obviously don't understand the concept of a production server. Multiple repo's is a waste of time and resources, not to mention it's defying the point of a VCS. Having a branch means everyone can push to the branch. That means the branch can get FUBAR'ed. Dev -> Staging -> Production. Production should **never** be updating itself with code. That is something you do when you're ready. Have more then a couple servers? Write a script and run it *once*. Not on a schedule.

Josh K 2010-08-10 18:32:08

If you're using git with more than 1 person you already have multiple repo's exactly what resources are you wasting? 5MB's to have another one? yes having a branch means everyone can push to it, who can push to the repo, which is why I suggest a separate repo, which everyone can't push to.

xenoterracide 2010-08-10 19:42:34

the only way that a server would ever update itself in my scenario is from the repo that's said 'this is production code'. otherwise it wouldn't get updated. I see little to no difference where you suggest pulling manually. Except that in my case all the servers could be cron-ed to update at the same time. You've got people wandering around updating each sever doing a pull.

xenoterracide 2010-08-10 19:44:58

btw, what is and isn't self updating is speculative... if the server checks for updates (from you) and then updates if it's found some. it's not updating itself, it's updating when you pushed the update.

xenoterracide 2010-08-10 19:50:20

@xeno: First, do a @Josh so I get notified when you reply. Second, you're wrong. People aren't wandering around to update each server. You have a production deployment, you go and push it to production. This could have to coincide with database schema changes, network changes, etc. Multiple repos is a waste of a VCS. Then what, you have a production repo that only contains production code? **WTF**. Might as well setup a server and `rsync` to update instead. I'm saying that having it automatically update itself is stupid, you think it's smart. Enough is enough.

Josh K 2010-08-11 02:15:33

@Josh I know this is going to come as a shock to you. But in all reality if your merge is a fast-forward an rsync isn't going to produce a different checkout from a git pull... (you know assuming your rsyncing a non-bare repo compared to pulling from a bare one) your repo might be different because things might not be packed as efficiently but it should work. Git's just files.

xenoterracide 2010-08-11 16:54:53

@xeno: My point wasn't that you're going to have different data, my point was you have different control over *when* it does that. This might come as a shock to you, but neither HTML nor CSS are **not** programming languages. ;) Might want to refresh yourself on some of the basics before you spout off telling someone how to properly run a production environment.

Josh K 2010-08-11 17:40:22

@Josh this might surprise you, but being able to program doesn't make you capable of doing systems administration.

xenoterracide 2010-08-11 20:12:58

@xeno: Says the guy who lists "creating a kiosk disk" among his many accomplishments.

Josh K 2010-08-11 20:45:05

@Josh does it make you feel like a big man to belittle people?

xenoterracide 2010-08-12 00:06:00

ansaurus

tags:

views:

answers:

How to release with Git?

related questions