How to release with Git?
Asked Answered
P

2

7

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!

Preoccupy answered 9/8, 2010 at 19:58 Comment(0)
D
2

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.

Decorticate answered 9/8, 2010 at 20:6 Comment(0)
W
-1

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.

Woodworker answered 9/8, 2010 at 20:18 Comment(17)
@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.Decorticate
'as long as' and don't work in the branch that's being checked out. get a sane workflow.Woodworker
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.Woodworker
@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.Decorticate
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.Woodworker
@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.Decorticate
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.Woodworker
@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.Decorticate
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.Woodworker
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.Woodworker
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.Woodworker
@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.Decorticate
@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.Woodworker
@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.Decorticate
@Josh this might surprise you, but being able to program doesn't make you capable of doing systems administration.Woodworker
@xeno: Says the guy who lists "creating a kiosk disk" among his many accomplishments.Decorticate
@Josh does it make you feel like a big man to belittle people?Woodworker

© 2022 - 2024 — McMap. All rights reserved.