kiranpyati [off-list ref] 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/
On Wed, Aug 8, 2012 at 7:20 AM, Matthieu Moy
[off-list ref] wrote:
kiranpyati [off-list ref] writes:
quoted
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.
Obligatory link to Sitaram's very helpful docs:
http://sitaramc.github.com/the-list-and-irc/deploy.html
Thanks to Sitaram for this very helpful guide.
That said, please pay close attention to everything Matthieu wrote
here. It seems like things will go smoothly once you "true things up"
and then follow a sensible process for moving things from git to
production going forward. Sitaram's write-up can help you discover
what the right process is for you.
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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
David
On Wed, Aug 8, 2012 at 10:20 AM, Matthieu Moy
[off-list ref] wrote:
kiranpyati [off-list ref] writes:
quoted
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.)
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 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
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)
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.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59