Git workflow

rubyonrails-talk
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

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.

3

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.

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.