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.
