On Wed, Aug 8, 2012 at 10:20 AM, Matthieu Moy
> kiranpyati <kiran.py...@infobeans.com> writes:
>> We want a way to seamlessly sync production and Git.
> You should be aware that Git was not designed for this scenario. The
> usual flow with Git (and actually with most revision control systems),
> is to do the development with Git, then use your build system to
> generate a package that can be used in production (e.g. generate a
> .tar.gz, or a .jar, or whatever your platform needs), and then install
> this package on your production server.
As I mentioned several days too late on a previous thread, the
assumption of formal packaging does not fit more than a few scenarios.
Certainly generating a tarfile sounds like a more reasonable solution
in many cases, but that requires discipline and plausible
deniability--you won't have a way of detecting if somebody didn't
follow the "official" deployment path. It is a sad fact that revision
control is probably the most sane way to detect this and deal with it
appropriately (without loosing work).
> It can be tempting, however, to use your revision control system as a
> deployment tool, so that an update on the production server be as simple
> as "git pull". But in real-life applications, it usually has to be more
> complicated: do you need to generate some files after you fetch the
> latest version of the source? Do you need to update your database?
If you are dealing with something updatable by just dropping a tar
file on it and walking away then a simple "git pull" will do just fine
(provided permissions and ACLs are set appropriately). If any of those
other concerns apply then you aren't talking about a simple file
update--you are talking about an application upgrade.
(Note: If you are using extended ACLs on a LINUX filesystem such as
ext2, ext3, or ext4, you won't have to worry about the git pull
flattening those--if you set them correctly--as that data is not part
of the content and container information that GIT tracks.)
> the .git/ directory harmfull here (e.g. do I want the full history
> source of my project to be visible worldwide if this is a
> webapplication?) ...
If you have configured your webserver correctly this is not an issue.
> If you insist in using Git for deployment, then you should absolutely
> stick to it. Whether for deployment or for anything else, trying to send
> changes using both Git and other mechanism (e.g. uploading files
> directly to a working tree as you did) puts you in trouble 99.9% of the
> In your case, the damage is already done. If I were you, I'd do
> something like
> <do some backup>
> <make sure the backup is OK>
> <think twice "will I be able to restore the backup if it goes wrong?">
> $ git fetch origin
> $ git reset --hard origin/master
> (actually, if I were you, I'd try reproducing the situation on a
> non-production server first)
Before doing this, do a "git diff -b -w" (ignoring whitespace changes)
to see how big the damage is and extract patches.
If you've planned things out well you won't be using the same branch
in production that you use for general development and therefore will
have the ability to use GIT to help get the changes made directly on
the production system into a temporary branch on another system for
proper merging, testing, and QA.
> "git fetch" will download the revisions from the remote server, which
> should be the repository where the version you want to run is located.
> "git reset --hard" will discard any local change (committed or not) you
> may have, and set your local working tree to the latest version in the
> master branch of the remote repository. You may need a "git clean" to
> remove untracked files too.
Then you can safely hard reset to the commit just prior the divergence
and pull the changes onto the production system--re-applying those
changes you discovered in the "git diff -b -w" step on a developer's
system first, in a temporary branch, before doing the reset, merging
back to development, etc.
So, in conclusion, this is a situation that can be dealt with if one
keeps his wits about him.
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html