On Wed, Aug 8, 2012 at 7:20 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > kiranpyati <kiran.pyati@xxxxxxxxxxxxx> 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. 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html