We are using git installed on a web server to develop with and we have placed a bare .git project outside of the public_html directory, and then we're cloning the master branch to a directory inside public_html. This allows us to push to the master branch without worrying about errors of the branch already being checked out.
We had the idea (and have checked it, works wonderfully so far) that we could checkout individual commit heads as a quick roll-back while we fix the master branch and pull again. Are there any known downsides or security issues we need to know about when doing this?
I'm not sure I completely understand the the setup you're using (two git repositories?) and reasoning behind it, but I got the sense that the actual question was about the roll-back procedure.
And rolling back by checking out individual commits is a completely valid approach and is in fact also a natural approach when using the gitflow
workflow suggested by Vincent Driessen: http://nvie.com/posts/a-successful-git-branching-model/
However, a key part of gitflow
is using git tag
to mark commits in the master branch as releases. A tag is a sort of 'commit-pointer' and checking out a tag will have the exact same effect as checking out the commit on to which it points.
These 'release tags' will typically be version numbers e.g '4.2', '1.2.3' etc. So in the case of having to do a roll-back when on tag, let's say '4.3', you simply do git checkout 4.2
and that will take you back to your latest stable release. This as opposed to having to look through your commit log, finding the right commit and then doing git checkout xyz
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With