December 16, 2008, 2:39am
Can someone answer a couple of Git questions that are puzzling me?
I have a repo on my Linux Server
I ‘git clone’ the repo on my laptop (xp)
I do some stuff
I do a ‘git add .’ and a ‘git commit -m “some comment”’
I do a ‘git push’ to the remote origin (Linux server)
Here is where it gets confusing…
On the Linux repo the “index” is updated but not the “working tree”
I have to do a ‘git reset --hard’ in order to see the laptop changes
on the server.
The question (finally) is:
what do I do if several people are trying to push to the server?. I
cant do a reset --hard as I will lose any changes somebody else has
What happens on GitHub when several people push to a repo?
I cant seem to find anything in the doco. Doing a pull or fetch/merge
from the remote repo seems to be the recommended method but GitHub
appears to use ‘pushes’.
Can anyone enlighten me or point me at some articles that may help.
December 16, 2008, 4:19am
Thanks for that Miles.
I had seen stuff about ‘bare repositories’ but didn’t know what they
Does an auto merge happen if two people push separately?
Can I convert my server repo to a bare repository or should start
Might have to change my Capistrano deploy as currently it does a file
copy from the repo folder rather than via git…
December 16, 2008, 2:43am
generally, what people do is use a “bare” repository as the main
repository. A bare repository has no working directory, and thus
doesn’t have this issue.
December 16, 2008, 4:43am
I would just create the bare repository, and then push to it. It’s
pretty straight forward, something like:
git init --bare
Then go to where ever you have an up-to-date branch in a repository
git push somemachine:/path/to/git/repos/project.git master
you should definitely be using git with capistrano instead of copying
working directories, yikes
when people push seperately, they have some options. The most
straight forward is to do a pull before doing a push. That way it
merges any commits that you’re missing. Even better is to use rebase
so that it always looks like a fast-forward push (ie, your history
isn’t full of merges that exist solely to get the lastest changes
since your last pull.)
you’ll probably have to read up on some of these concepts.
December 16, 2008, 3:30pm
Jon Loeliger’s book on Git should be in O’Reilly’s Rough Cuts very
soon. I am editing the book and am finding it well-written and