{"thread":{"id":"31210","subject":"Sync production with Git","startedAt":"2012-08-08T13:11:24Z","lastAt":"2012-08-09T04:25:29Z","messageCount":6,"participants":["kiranpyati","Matthieu Moy","David Aguilar","Drew Northup","demerphq"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196666","messageId":"1344431484059-7564617.post@n2.nabble.com","threadId":"31210","inReplyTo":null,"subject":"Sync production with Git","fromName":"kiranpyati","fromEmail":"kiran.pyati@infobeans.com","sentAt":"2012-08-08T13:11:24Z","receivedAt":"2012-08-08T13:11:24Z","isPatch":false,"sender":{"key":"kiran.pyati@infobeans.com","avatar":null},"body":"I am new to github,\n\nEarlier we used to manually upload files on the production through FTP\nalthough git was present on the production. Due to this now git status shows\nmany modified and untrack files.\n\nTo sync that with git we have downloaded all files from production and\ncommitted to git. Now git has all files same as production.\n\nWe have not pulled on production since last 6 months and because of this it\nshows modified and untracked files.\n\nNow if we pull on the production there any 100% chances of the conflict\nhappened on all modified files. As there are hundreds of modified files\nsince last since month. Git pull will show conflict to all those files. In\nthat case site will get down and we can not afford this.\n\nWe want a way to seamlessly sync production and Git.\n\nCan anybody please help me on this?\n\nThanks in advance..!!\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Sync-production-with-Git-tp7564617.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"196669","messageId":"vpqlihpbh4f.fsf@bauges.imag.fr","threadId":"31210","inReplyTo":"1344431484059-7564617.post@n2.nabble.com","subject":"Re: Sync production with Git","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-08-08T14:20:00Z","receivedAt":"2012-08-08T14:20:00Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"kiranpyati writes:\n\n> We want a way to seamlessly sync production and Git.\n\nYou should be aware that Git was not designed for this scenario. The\nusual flow with Git (and actually with most revision control systems),\nis to do the development with Git, then use your build system to\ngenerate a package that can be used in production (e.g. generate a\n.tar.gz, or a .jar, or whatever your platform needs), and then install\nthis package on your production server.\n\nIt can be tempting, however, to use your revision control system as a\ndeployment tool, so that an update on the production server be as simple\nas \"git pull\". But in real-life applications, it usually has to be more\ncomplicated: do you need to generate some files after you fetch the\nlatest version of the source? Do you need to update your database? Isn't\nthe .git/ directory harmfull here (e.g. do I want the full history\nsource of my project to be visible worldwide if this is a\nwebapplication?) ...\n\nIf you insist in using Git for deployment, then you should absolutely\nstick to it. Whether for deployment or for anything else, trying to send\nchanges using both Git and other mechanism (e.g. uploading files\ndirectly to a working tree as you did) puts you in trouble 99.9% of the\ncases.\n\nIn your case, the damage is already done. If I were you, I'd do\nsomething like\n\n\n\n\n$ git fetch origin\n$ git reset --hard origin/master\n\n(actually, if I were you, I'd try reproducing the situation on a\nnon-production server first)\n\n\"git fetch\" will download the revisions from the remote server, which\nshould be the repository where the version you want to run is located.\n\"git reset --hard\" will discard any local change (committed or not) you\nmay have, and set your local working tree to the latest version in the\nmaster branch of the remote repository. You may need a \"git clean\" to\nremove untracked files too.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"196714","messageId":"CAJDDKr5=zDEn4j9HAp3k5ubOJ1g5J-VhAka=BpoNuJbJ+ES_og@mail.gmail.com","threadId":"31210","inReplyTo":"vpqlihpbh4f.fsf@bauges.imag.fr","subject":"Re: Sync production with Git","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-08-08T22:35:53Z","receivedAt":"2012-08-08T22:35:53Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Wed, Aug 8, 2012 at 7:20 AM, Matthieu Moy\n wrote:\n> kiranpyati writes:\n>\n>> We want a way to seamlessly sync production and Git.\n>\n> You should be aware that Git was not designed for this scenario. The\n> usual flow with Git (and actually with most revision control systems),\n> is to do the development with Git, then use your build system to\n> generate a package that can be used in production (e.g. generate a\n> .tar.gz, or a .jar, or whatever your platform needs), and then install\n> this package on your production server.\n\n\nObligatory link to Sitaram's very helpful docs:\n\nhttp://sitaramc.github.com/the-list-and-irc/deploy.html\n\nThanks to Sitaram for this very helpful guide.\n\n\nThat said, please pay close attention to everything Matthieu wrote\nhere. It seems like things will go smoothly once you \"true things up\"\nand then follow a sensible process for moving things from git to\nproduction going forward. Sitaram's write-up can help you discover\nwhat the right process is for you.\n\n\n> It can be tempting, however, to use your revision control system as a\n> deployment tool, so that an update on the production server be as simple\n> as \"git pull\". But in real-life applications, it usually has to be more\n> complicated: do you need to generate some files after you fetch the\n> latest version of the source? Do you need to update your database? Isn't\n> the .git/ directory harmfull here (e.g. do I want the full history\n> source of my project to be visible worldwide if this is a\n> webapplication?) ...\n>\n> If you insist in using Git for deployment, then you should absolutely\n> stick to it. Whether for deployment or for anything else, trying to send\n> changes using both Git and other mechanism (e.g. uploading files\n> directly to a working tree as you did) puts you in trouble 99.9% of the\n> cases.\n>\n> In your case, the damage is already done. If I were you, I'd do\n> something like\n>\n> \n> \n> \n> $ git fetch origin\n> $ git reset --hard origin/master\n>\n> (actually, if I were you, I'd try reproducing the situation on a\n> non-production server first)\n>\n> \"git fetch\" will download the revisions from the remote server, which\n> should be the repository where the version you want to run is located.\n> \"git reset --hard\" will discard any local change (committed or not) you\n> may have, and set your local working tree to the latest version in the\n> master branch of the remote repository. You may need a \"git clean\" to\n> remove untracked files too.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n\n-- \nDavid\n"},{"id":"196721","messageId":"CAM9Z-nkj0q9qb0pFU50HZc6Ka6ScUVD+wyROnq9NVf2fS03kww@mail.gmail.com","threadId":"31210","inReplyTo":"vpqlihpbh4f.fsf@bauges.imag.fr","subject":"Re: Sync production with Git","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2012-08-09T03:46:04Z","receivedAt":"2012-08-09T03:46:04Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Wed, Aug 8, 2012 at 10:20 AM, Matthieu Moy\n wrote:\n> kiranpyati writes:\n>\n>> We want a way to seamlessly sync production and Git.\n>\n> You should be aware that Git was not designed for this scenario. The\n> usual flow with Git (and actually with most revision control systems),\n> is to do the development with Git, then use your build system to\n> generate a package that can be used in production (e.g. generate a\n> .tar.gz, or a .jar, or whatever your platform needs), and then install\n> this package on your production server.\n\nAs I mentioned several days too late on a previous thread, the\nassumption of formal packaging does not fit more than a few scenarios.\nCertainly generating a tarfile sounds like a more reasonable solution\nin many cases, but that requires discipline and plausible\ndeniability--you won't have a way of detecting if somebody didn't\nfollow the \"official\" deployment path. It is a sad fact that revision\ncontrol is probably the most sane way to detect this and deal with it\nappropriately (without loosing work).\n\n> It can be tempting, however, to use your revision control system as a\n> deployment tool, so that an update on the production server be as simple\n> as \"git pull\". But in real-life applications, it usually has to be more\n> complicated: do you need to generate some files after you fetch the\n> latest version of the source? Do you need to update your database?\n\nIf you are dealing with something updatable by just dropping a tar\nfile on it and walking away then a simple \"git pull\" will do just fine\n(provided permissions and ACLs are set appropriately). If any of those\nother concerns apply then you aren't talking about a simple file\nupdate--you are talking about an application upgrade.\n\n(Note: If you are using extended ACLs on a LINUX filesystem such as\next2, ext3, or ext4, you won't have to worry about the git pull\nflattening those--if you set them correctly--as that data is not part\nof the content and container information that GIT tracks.)\n\n> Isn't\n> the .git/ directory harmfull here (e.g. do I want the full history\n> source of my project to be visible worldwide if this is a\n> webapplication?) ...\n\nIf you have configured your webserver correctly this is not an issue.\n\n> If you insist in using Git for deployment, then you should absolutely\n> stick to it. Whether for deployment or for anything else, trying to send\n> changes using both Git and other mechanism (e.g. uploading files\n> directly to a working tree as you did) puts you in trouble 99.9% of the\n> cases.\n>\n> In your case, the damage is already done. If I were you, I'd do\n> something like\n>\n> \n> \n> \n> $ git fetch origin\n> $ git reset --hard origin/master\n>\n> (actually, if I were you, I'd try reproducing the situation on a\n> non-production server first)\n\nBefore doing this, do a \"git diff -b -w\" (ignoring whitespace changes)\nto see how big the damage is and extract patches.\n\nIf you've planned things out well you won't be using the same branch\nin production that you use for general development and therefore will\nhave the ability to use GIT to help get the changes made directly on\nthe production system into a temporary branch on another system for\nproper merging, testing, and QA.\n\n> \"git fetch\" will download the revisions from the remote server, which\n> should be the repository where the version you want to run is located.\n> \"git reset --hard\" will discard any local change (committed or not) you\n> may have, and set your local working tree to the latest version in the\n> master branch of the remote repository. You may need a \"git clean\" to\n> remove untracked files too.\n\nThen you can safely hard reset to the commit just prior the divergence\nand pull the changes onto the production system--re-applying those\nchanges you discovered in the \"git diff -b -w\" step on a developer's\nsystem first, in a temporary branch, before doing the reset, merging\nback to development, etc.\n\nSo, in conclusion, this is a situation that can be dealt with if one\nkeeps his wits about him.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"196722","messageId":"CANgJU+VNA-Rz_MqfowKjTYQWFeYdfbwJZKvQdfv+Qbu0J6YudQ@mail.gmail.com","threadId":"31210","inReplyTo":"1344431484059-7564617.post@n2.nabble.com","subject":"Re: Sync production with Git","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-08-09T04:21:21Z","receivedAt":"2012-08-09T04:21:21Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 8 August 2012 15:11, kiranpyati wrote:\n> I am new to github,\n>\n> Earlier we used to manually upload files on the production through FTP\n> although git was present on the production. Due to this now git status shows\n> many modified and untrack files.\n>\n> To sync that with git we have downloaded all files from production and\n> committed to git. Now git has all files same as production.\n>\n> We have not pulled on production since last 6 months and because of this it\n> shows modified and untracked files.\n>\n> Now if we pull on the production there any 100% chances of the conflict\n> happened on all modified files. As there are hundreds of modified files\n> since last since month. Git pull will show conflict to all those files. In\n> that case site will get down and we can not afford this.\n>\n> We want a way to seamlessly sync production and Git.\n>\n> Can anybody please help me on this?\n>\n> Thanks in advance..!!\n\nTry git-deploy.\n\nhttps://github.com/git-deploy\n\nIt contains a full work flow management for handling rollouts from git.\n\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"196723","messageId":"CANgJU+VLFPb8xm-qqk5m0WhzEEgtJAjq9xzcunWe5ShVLyNG=Q@mail.gmail.com","threadId":"31210","inReplyTo":"CANgJU+VNA-Rz_MqfowKjTYQWFeYdfbwJZKvQdfv+Qbu0J6YudQ@mail.gmail.com","subject":"Re: Sync production with Git","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-08-09T04:25:29Z","receivedAt":"2012-08-09T04:25:29Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 9 August 2012 06:21, demerphq wrote:\n> On 8 August 2012 15:11, kiranpyati wrote:\n>> I am new to github,\n>>\n>> Earlier we used to manually upload files on the production through FTP\n>> although git was present on the production. Due to this now git status shows\n>> many modified and untrack files.\n>>\n>> To sync that with git we have downloaded all files from production and\n>> committed to git. Now git has all files same as production.\n>>\n>> We have not pulled on production since last 6 months and because of this it\n>> shows modified and untracked files.\n>>\n>> Now if we pull on the production there any 100% chances of the conflict\n>> happened on all modified files. As there are hundreds of modified files\n>> since last since month. Git pull will show conflict to all those files. In\n>> that case site will get down and we can not afford this.\n>>\n>> We want a way to seamlessly sync production and Git.\n>>\n>> Can anybody please help me on this?\n>>\n>> Thanks in advance..!!\n>\n> Try git-deploy.\n>\n> https://github.com/git-deploy\n>\n> It contains a full work flow management for handling rollouts from git.\n\nBetter link:\n\nhttps://github.com/git-deploy/git-deploy\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"}]}