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

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.

  • Git understanding behaviour of checkout branch and presence and absence of files
  • git checkout HEAD~2 (example) deletes untracked files if they were added with last commit.
  • git checkout automatically merges local modifications
  • How to checkout latest stable Boost (not development or bleeding edge)?
  • git: Switch branch and ignore any changes without committing
  • Check git current file version and how to handle removed files
  • 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?

  • How can I push a local Git branch to a remote with a different name easily?
  • git: mixed up branches - how to clean up
  • Django, Python Modules, and Git Submodules
  • How can I push a git repo to a remote server through ssh?
  • Git fatal: Reference has invalid format: 'refs/heads/master
  • Is it possible to specify git.exe location during server-side checkout
  • 2 Solutions collect form web for “Git Deployment: How to rollback to previous stable version of my app?”

    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

    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.

    Git Baby is a git and github fan, let's start git clone.