6

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?

Zoe
  • 27,060
  • 21
  • 118
  • 148
George D.
  • 1,630
  • 4
  • 23
  • 41

2 Answers2

4

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.

Tadeas Kriz
  • 524
  • 4
  • 14
  • If you have a problem after the merge of develop to master, what are you going to do to revert the master to the state before the merge? Is there any kind of "Revert to previous Tag" command? I am still reading it, its a very cool article indeed. – George D. Oct 31 '12 at 10:20
4

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

prusswan
  • 6,853
  • 4
  • 40
  • 61
  • hm...databases is an issue to this kind of thing. Although I am using Laravel that has a Version Control like approach for DB. But anyway I see your point. I really thank you for your time :-) – George D. Oct 31 '12 at 10:23
  • Should you also have said that after doing 'git add . ' and committing the changes, he'll need to do 'git push --force' since the remote repo still has the old version of the code that will need to be over-written? – Jim Apr 08 '20 at 04:58
  • @Ray at that time I am not sure if I wanted to recommend a force push (which will have to be prefaced with more warnings) - but he likely would have figured that on his own – prusswan Apr 08 '20 at 07:42