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

Question

I seriously think of using git as my deployment method. I am currently working alone, so conflicts are not a problem in my case. Suppose I followed the steps to replicate a workflow that connects my localhost, my bitbucket account, and my resident server. I keep wondering how to insure if something breaks, I can safely return to the stable version.

The only thing I can think of is to create a branch for each future version and then check it out. If this is not normal or I have problems, I will return to the master. If this is normal, I will merge the branch with the master in a few days, and I will create a new branch.

Is that logical? I searched a lot of articles on this topic, but I really can not understand most of them, because they are for medium-sized teams, so the workflow is different. I also asked the same question on some sites and did not receive an answer, most likely became stupid, I really don’t know. But here I am. How will the version work in my case?

Answer 1

At first, I assume that you have no problem deploying any particular branch.

In environments with some semblance of professionalism (and budget), there would be an intermediate environment in which the new code will be deployed before it starts working (in your case, in the repository of a real server). Usually, the production version should always be stable (hint: if it wasn’t the case, you should have noticed it before it ended, and good testing methods would also be useful here)

Now let's assume that you still have to “fix” the master for production, and the usual revert is not enough, one way to do this is:

• Reset - set the desired commit
• Reset (soft) to the head of the wizard (now your working copy will still be from the desired commit)
• Configure the current working copy (i.e. git add . ) And commit it.

PS: Note that I do not do this often, and I hope that you will not do it, especially on the main

One more warning: this will not take care of database backups, you will need other contingency plans for these

Answer 2

Read this article: Successful Git Branching Model

In our company, we use this approach, and it was very useful. Basically, this is what you have already talked about, but it also says that you have a “leading” branch for release of assemblies and “development” of a branch into which you merge all branches of functions, and when you are ready to publish a new one version, you simply combine the development of the branch into a wizard and create a new tag. As I said, read the article on how this helped me create a stable branching model.