From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: kiranpyati <kiran.pyati@infobeans.com>
Cc: git@vger.kernel.org
Subject: Re: Sync production with Git
Date: Wed, 08 Aug 2012 16:20:00 +0200 [thread overview]
Message-ID: <vpqlihpbh4f.fsf@bauges.imag.fr> (raw)
In-Reply-To: <1344431484059-7564617.post@n2.nabble.com> (kiranpyati's message of "Wed, 8 Aug 2012 06:11:24 -0700 (PDT)")
kiranpyati <kiran.pyati@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.
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? Isn't
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 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
cases.
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)
"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.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2012-08-08 14:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 13:11 Sync production with Git kiranpyati
2012-08-08 14:20 ` Matthieu Moy [this message]
2012-08-08 22:35 ` David Aguilar
2012-08-09 3:46 ` Drew Northup
2012-08-09 4:21 ` demerphq
2012-08-09 4:25 ` demerphq
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqlihpbh4f.fsf@bauges.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=kiran.pyati@infobeans.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).