pkromer
asked on
Git repo snapshot, yes ot no?
Is it necessary to do a Git snapshot when we want to have a copy of our code base for our stable website? I had posted a question here about *how* best to create a Git snapshot, but I didnt ask *why*. I got to thinking after that... our web host has daily backups on the server of our entire site, and if anything goes wrong or we push some code from Github to our live site and it breaks something, couldnt we just have our web host restore all the files from the server backup to a date before we screwed things up? I know there would then be an issue of how to get our Github repo reverted back to that date and not lose all our subsequent changes, but maybe thats a better approach then trying to schedule snapshots of our stable site. I'm not sure, though, so Im looking for opinions here.
ASKER
Yeah, I dont even know how to word this issue. Bottom line is:
How do we revert to the last stable version of our web site if a Git push to production goes sideways?
How do we revert to the last stable version of our web site if a Git push to production goes sideways?
By getting the previous version from your git repository.
ASKER
But we may have had a few commits since the last stable version of our website, which may corrupt the stable version of the code now on the production server... what we want is a copy of our repo at the time we have deemed our website stable, which will always be X number of hours or days after the last push to production.
Each commit to Git repository is a snapshot. It is marked by date/time and name (who did it). When you use Git the simplest way, you create the chain (list) of commits -- linear history.
It is easy to create a new branch at each commit. So, you can pick a specific commit point (the snapshot), create the branch, and checkout that new branch. This way you get the exact copy of all files as they were in the commit time.
You can also "mark" some of the commits by your git tag (say, you created new version, and you want to mark for you "it is here"). This means you can find the commit point later in future more easily. Anyway, it is only a helper.
Again, each commit point in Git is "a snapshot".
It is easy to create a new branch at each commit. So, you can pick a specific commit point (the snapshot), create the branch, and checkout that new branch. This way you get the exact copy of all files as they were in the commit time.
You can also "mark" some of the commits by your git tag (say, you created new version, and you want to mark for you "it is here"). This means you can find the commit point later in future more easily. Anyway, it is only a helper.
Again, each commit point in Git is "a snapshot".
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanks guys
Then I have to admit: I don't understand that question either. That code should be read-only. There is no reason for changing code on the production server. It should be only checked out.