Git Deployment: How to rollback to previous stable version of my app?

Question

I am seriously thinking to use git as my deployment method. Currently I work alone so conflicts is not a problem in my case. Lets say that I followed the steps to replicate a workflow that connects my localhost, my bitbucket account and my live server repository. I keep wondering how to insure that if anything breaks, I can safely get back to the stable version.

Only thing I can think is to create a branch for each future version and then checkout to it. If its not ok or I have problems I'll checkout back to master. If its ok, I merge the branch with master after a few days and I'll create a new branch.

Is this logical? I have searched many articles on the subject but I really can't understand most of them, because they are for mid-large teams so the workflow is different. Also I have made the same question to some sites and never got an answer, most probably cause its a stupid one, I really don't know. But here I am. How versioning will work in my case?

Answer 1

First I would assume you have no problems deploying any specific branch.

In environments with some semblance of professionalism (and budget), there would be a staging environment where new code will be deployed before it gets to production (in your case, the live server repository). Generally the version on production should always be stable (hint: and in the case when it is not, you should have spotted it before it ended up on production, good testing practices will also be helpful here)

Now, let's suppose you ended up having to "hot-fix" master for production anyway and the regular revert happens to be insufficient, one way to do this is to:

1. Reset --hard to the desired commit
2. Reset (soft) to head of master (now your working copy will still be from the desired commit)
3. Stage the current working copy (i.e. git add .) and commit it.

PS: Note that I don't do this often and I hope you don't either, especially on master

Another note of warning: this does not take care of database backups, you will need other contingency plans for those

Answer 2

Please read this article: A successful Git branching model

In our company we use this approach and it has been very helpful. Basically it's something you've already said, but this thinks also about the thing that you have "master" branch for releasing builds and "develop" branch into which you merge all feature branches and when you're ready to publish new release, you simply merge develop branch into master and create new tag. As I said, read the article as it's what helped me to create stable branching model.