Bryan Helmkamp - Our Git deployment workflow Comments

Comment on 'Our Git deployment workflow' by Chris Hoeppner

2008-08-21T15:40:58Z

The whole procedure looks like you’re using git as if it was subversion. Hard resets, forced pushes, etc, built into everything.

Comment on 'Our Git deployment workflow' by Bryan Helmkamp

2008-08-16T03:50:27Z

Good point, Tammer. I’ll see about checking for success response codes.

Comment on 'Our Git deployment workflow' by Tammer Saleh

2008-08-15T13:42:31Z

Bryan – this is a great post, and looks very useful. We’re just starting to move some of our rails apps to git, and this will definitely be helpful. One comment on the script: you’re not checking the return values of any of the git commands. If one of them fails, (like git co xxx), then the rest of the commands (like git reset—hard) will still run. I’m not sure what kind of problems this could cause.

Comment on 'Our Git deployment workflow' by Micah Geisel

2008-08-11T21:19:13Z

thanks for the post, i’ve been attempting to standardize a similar git workflow for my team, and its interesting to see another’s implementation. so please continue posting as this matures. quick thought: change your GitCommands instance methods to class methods, and you can eliminate the ‘new’ keyword in your calls.

Comment on 'Our Git deployment workflow' by Bryan Helmkamp

2008-08-10T21:48:35Z

Henrik—Fixed thanks.

Jesse—That was my original reaction as well when we’re setting this up, and a few other people have shared similar comments. Functionally, we’re leveraging git’s branches as if they were tags that we can replace at will across our remotes. Because we never commit to the staging and production branches directly (which our rake tasks help enforce), we never lose history.

We’re interested in alternatives, and one of the reasons I posted this is to see if people had suggestions on how we could do better.

Looking at the docs for git-merge, I wonder if instead of a reset—hard we could do a merge using the “ours” strategy. That might let us workaround the problem with a vanilla merge, where we just want to replace instead and not deal with conflicts.

There’s also the possibility that it can be better done with tags, but from my brief experiments that seems to be problematic. We’d also have to force push tag updates, which I’m not sure is any better.

Thoughts?

Comment on 'Our Git deployment workflow' by Jesse Andrews

2008-08-07T00:48:24Z

I’ve simplified tag_staging, tag_production, branch_production – check out gist 4294.

BUT I really really really think this is wrong. (not the ruby code, but the methodology).

You are loosing the best parts of Git by continually rewriting history. Any time you see a push -f or reset in the normal flow you are miss-using git.

Anyone can stage a branch that isn’t a descendant of origin/production then rake tag:production. All of a sudden all that history is gone!

Comment on 'Our Git deployment workflow' by Henrik N

2008-08-06T23:02:20Z

Nice.

tag\_producton -> tag\_production

Comment on 'Our Git deployment workflow' by Chris

2008-08-06T05:05:56Z

Thanks for sharing. I’ve put up your rake tasks as a Gist: http://gist.github.com/4169