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?
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:
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