Switching Where A Branch Points To In Git

We are looking for a clean way to use git in our web deployment process. What we want to do it be able to have a branch called release and basically whenever we deploy, it just deploys the code from that branch. This seems easy enough as all we have to do it merge our change into the release branch and also create another branch (that will match the release branch at that time) for the version (so a branch called 1.1.1). The question is about what we can do in the event of needing a rollback. So say we have branches 1.1.0 and 1.1.1. We release 1.1.2 and those changes are merged into the release branch and another branch called 1.1.2 is created. We need notice a makor bug that requires use to rollback to version 1.1.1. Is there a clean way to just have the release branch point to 1.1.1

It seems like the ideal solution is to have some way to have something (whether is is a branch, tag, whatever) that we don't actually push anything to, we just use it to point to another branch. This way when a new version comes out, we create a branch for that version and that just point release to that branch. I开发者_运维问答f we need to rollback, we just switch the release to point to that last know working branch. Is something like this possible.

Just create a tag called currently_live or something like that and point it to a particular commit, just so that you all now what's currently deployed.

That would be completely independent from your branching policies which will ideally have a master branch and separate versioned branch.

By using git tag -f ... you can move the tag around when you need to.

A branch in Git is just a pointer to a particular version of the code. So you can have a release branch, and push any given version of the code to that branch. Now, Git will normally make sure that anything new you push to a branch is a child of what is already on that branch, to prevent you from accidentally losing history. But if you're using a branch like release in which you intend to be able to downgrade, you can override that by adding a + to the refspec when you push.

Let's say you have tags v1.1.1 and v1.1.2, and you want to downgrade your release to v1.1.1. I'm also assuming your deployment remote is named deploy, and it has a branch named release which will be checked out in your deployment process. You could just write:

git push deploy +v1.1.1:release

I would revert the changes as a new commit (git revert) and call it "1.1.3". This avoids confusion, why someone can travel backwards in time :)

Use git-update-ref

git update-ref -m "new release" --no-deref releasebranch ref:origin/maint

It also allows a "ref" file to be a symbolic pointer to another ref file by starting with the four-byte header sequence of "ref:".