On Sat, Sep 20, 2014 at 4:02 AM, Tom Hopcraft <[email protected]> wrote: > Hi, > > I have just moved host and my old git setup was to have a working repo on > the server and then clone that working repo locally. I also run Wordpress > and when I upload files through Wordpress this would add files to the live > hosting that I would not have locally. To get this locally I would have to > SSH into the server and git add -A and commit them, I would then fetch them > locally. > > -- > > I have done some reading up about the best way to migrate git repo's to new > servers as I'd like to keep my history, naturally. > > I have read that the live server shouldn't have a working repo but a bare > repo. That is fine by me, but then how do I SSH in and find the files ?
You don't. All the files in a bare repository are in git's internal "compressed" format. It is not intended that anyone SSH into the server and access the bare repository as if it were a normal, working, directory. > The > root on the server now contains foo.git and no files where as a working repo > would contain a hidden .git and then foo.html, bar.html. Very true. This is how git is designed. > > I'm confused as to why you shouldn't use a working repo on the server and if > you are to use a bare repo, how does example.com/foo.html get found ? A bare repository is not a working directory. It is meant to be a source/sink for git clone or fetch and git push. Just like an Subversion server is not to be used as a place to modify the files managed by the Subversion system. > > Thanks Basically, the way that I think of it, is that the bare repository is the "off site" storage location where the "master copy" is kept. When you want to do work on a project, you first do a "git clone" to create a working directory on your work PC (which might or might not be the same physical system). This creates a new directory on your machine. This directory contains a .git subdirectory which contains all of the git repository information (all versions of all files) and also contains a current working copy of the files themselves. You modify these files. Periodically, as you think necessary or according to some standard, you do a "git add" of the files you have changed and sometime (perhaps immediately) afterwords do a "git commit" to put the modified files and a comment into _your local_ version of the project. Again, at some point in time, you do a "git push". This contacts the PC which contains the bare repository (aka the "git server") and tries (explain in a bit) to update it with your changes. This may or may not succeed. It will fail if someone else has updated the bare repository after your last "git fetch" of it. You must then "git fetch" and do a "git merge" to merge the bare repositories view of the project with your local view. If this succeeds, then do a "git push" again and you are finished. Otherwise, you will be told by "git merge" that there is a conflict that you must resolve. Once you do that, you can do a the "git add", "git commit", and "git push" sequence again to update the bare repository. I hope that I made some sense to you. I often don't. <sigh/> BTW - I don't know anything about WordPress, so I can't make any comment about that. But perhaps these will help: http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git http://premium.wpmudev.org/blog/improve-wordpress-development-workflow-local-server/ http://efeqdev.com/website-development/this-is-how-we-version-control-and-deploy-our-wordpress-websites-with-git/ -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
