On Tue, 16 Jun 2015 04:08:39 -0700 (PDT) Chad Baloga <cbal...@gmail.com> wrote:
> I am fairly new to GIT. Just Git or git. It's not an acronym ;-) > When we do a push to the remote repo, the Working Copy on the remote > does not get updated automatically. Do you mean the work tree? In other words, do you mean the copy of files which are checked out -- the same as in your local repository, where you actually change the files and then commit the changes? If yes, as they say, you're doing it wrong. Forget about your server for a moment and imagine what should actually happen when you're sitting here hacking on another feature and then somebody pushes something to your local repository -- what should happen? Do you expect all your changes should suddenly disappear -- being replaced with whatever has just been pushed? I reckon, your answer would be "obviously, no!" ;-) But the thing is, Git absolutely does not care whether a repository is "local" or "on the server" -- Git is able to extract history from a repository and send it to another Git instance, and it is able to receive history from another Git instance and place it into the repository -- end of the story. Everything else is just policy. To absorb this idea better, just `cd` to another directory on your local filesystem and do git init . git clone /path/to/your/local/repo . git branch joke git push origin joke ...you'll then find a branch named "joke" in your original repository. Is that repository "remote"? For our new repository we've just created in the snippet above -- definitely yes; is it remote in your eyes? -- supposedly no. The same goes for "truly remote" repositories: they are deemed to be remote because no one works in them directly, and they only get updated (via pushes) and queried (via fetches) from "clients". That's how we arrive to this simple fact: work trees are for programmers. The only way to update the work tree is to manually tell Git you want it based on such and such commit. There's no way to make Git somehow automatically update the repository's work tree when that repository receives new history. Now there's such thing as "hooks": Git is able to run programs (typically scripts) when certain event happens in the repository -- say, the new stuff has just been pushed and some branches updated. That's exactly what people who still want to use Git as a deployment tool use: set up a post-update hook to check out stuff from some dedicated branch and be done with it. The hook is also able to compensate for features lacking in Git-as-a-deployment-tool: it does not store file ownership and access bits / ACLs. The final point to consider is that for normal repos (those with the work tree, that is, non-bare) Git by default disallows pushing to the branch is which is currently checked out. This is simply to remove the WTF-factor when your index all of a sudden is out of sync with the branch it's based on (read the official GIt FAQ for more). Because of all of the above, deployment is typically done to a bare repository which has a post-update hook which uses lower-level Git commands to populate/update work tree *disjoint* from that repository. Just google for more, and see [1]. Note that you might consider not using Git for deployment at all. For instance, things like git-ftp work really OK for PHP projects. 1. https://groups.google.com/d/topic/git-users/Lvv7ByIZZ1o/discussion -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.