Git workflow


#1

Hi,
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
made.

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.

Thanks
George


#2

Thanks for that Miles.

I had seen stuff about ‘bare repositories’ but didn’t know what they
were.

Does an auto merge happen if two people push separately?

Can I convert my server repo to a bare repository or should start
again?

Might have to change my Capistrano deploy as currently it does a file
copy from the repo folder rather than via git…

G.


#3

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.


#4

I would just create the bare repository, and then push to it. It’s
pretty straight forward, something like:

mkdir project.git
cd project.git/
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.


#5

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
informative.