Version Control (GIT) shared access??

MuGeN · 19 Dec 2009 at 10:48

Ok, so I've installed git, and i understand how to clone a copy of the project and checkout new branches etc etc (all through the terminal on my mac - haven't looked at GUIs yet...)

What I want to know is a fundamental thing that I'm unsure of, and that is how to collaborate with this system...

is it as simple as giving people access to a certain folder on my computer via SSH or something? I've got to admit file sharing is not a strong point of mine I've never managed to reliably set up sharing across a network (between macs and pcs) never mind over the tinterweb...

is it a case of doing port forwarding and all that jazz so that someone can get to a folder and then run their $ git whatever commands to pull down copies and all that, or is there a more elegant way of setting it up?

if this is the case, I also don't know the best way to just share one folder on my mac - if i set up a "Sharing Only" user then windows people cant get in, and if I set up a full user on my mac just to get into the repository, then they get access to loads of other stuff too which I don't want...

all in all, could do with a leg up... any advice?

MuGeN · 20 Dec 2009 at 11:58

ho-kay, so i've managed to set things up so i can ssh into my work computer and get around the file system and work with the repository there, so the only fundamental thing which needs properly setting up is how other people should have access, i am obviously logging in with my own details but how would i go about setting up a user which simply has access to one folder on my computer and nothing else? don't even want them to have a home directory to be honest...

could someone help me out?

Pho · 20 Dec 2009 at 16:38

Is there any reason you're using GIT? Subversion is much easier to set-up for this. GIT looked painful

.

MuGeN · 20 Dec 2009 at 21:42

Pho said:
Is there any reason you're using GIT? Subversion is much easier to set-up for this. GIT looked painful .

well, i just did a lot of reading over which to go for and the consensus seemed to be that if you are used to svn then stick with it unless the git advantages are particularly suitable for what you are doing, but if starting fresh git seemed to come across as a fresher take on the idea and better in most ways...

do you not agree? git itself doesn't seem hard to get around but i admit the fact that there is more than one repository makes it a bit more complex...

i might have a go with svn since we haven't started the collaboration yet i'm still learning the whole thing, so maybe worth a dabble to make my own mind up...

EDIT: its worth googling "subversion git" - vast majority of sites are taking about "why you should switch to git" or "10 reasons why git is better than subversion" and all that... based on all this stuff i went for git

Pho · 21 Dec 2009 at 11:19

I started with SVN so I'm probably just more partial towards it. I've used it to host several projects under one repository with several users each having select permissions to each project.

When I last looked into it (a few months ago) the tools just didn't seem to be around for Windows at the time, I love TortoiseSVN but the GIT version seemed buggy and I couldn't find much else.

In SVN you can setup svnserve so you can access the repositories with svn://ip

ort/trunk/project/ etc so there must be something similar for GIT.

Defenestration · 22 Dec 2009 at 00:03

Check out the book, Pro Git, which happens to be available for free on-line. It's excellent, and may help with your query (particularly chapter 4)

http://progit.org/book/

Sic · 22 Dec 2009 at 10:01

I started with subversion and now use git for all new repositories - it's MUCH better for a production environment, in my opinion. Subversion will cry and make things difficult if you try to do anything out of the ordinary (if you accidentally delete a file, you have to update and use svn to remove it otherwise it goes weird) and the linear nature of it makes the "I know you're working on a new version of our site, but can we just make this tiny change?" instances much easier by just being able to branch from a point, make your changes, then merge back into master. Those two things make it head and shoulders above SVN for me.

As Defenestration says, Pro Git is an excellent resource in plain English.

dave-lew99 · 22 Dec 2009 at 10:19

Why don't you use the windows version og GIT?

http://code.google.com/p/msysgit/

Personally i like SVN - will serve over a variety of protocols including Apache/HTTP and clients for all platforms - including a windows GUI client to make it nice and easy.

MuGeN · 22 Dec 2009 at 10:40

Sic said:
I started with subversion and now use git for all new repositories - it's MUCH better for a production environment, in my opinion. Subversion will cry and make things difficult if you try to do anything out of the ordinary (if you accidentally delete a file, you have to update and use svn to remove it otherwise it goes weird) and the linear nature of it makes the "I know you're working on a new version of our site, but can we just make this tiny change?" instances much easier by just being able to branch from a point, make your changes, then merge back into master. Those two things make it head and shoulders above SVN for me.

As Defenestration says, Pro Git is an excellent resource in plain English.

since it sounds like you use git to collaborate on web projects, could you tell me what you do about databases? obviously a db is not something that would be passed around with clones, pushes and pulls?

(btw: thanks for the heads up on Pro Git, read a few chapters and now I've ordered the paper version to support the writer

)

Sic · 22 Dec 2009 at 16:19

Sure! I've actually got a few little techniques that you might find useful. Basically, seeing as you don't need the /trunk /branches /tags folder structure that serves well with SVN, I go for the following:

/docs
/html
/install

docs contains anything you might need to keep track of - proposals, images, wireframes, whatever.

html contains all the code of the project

install contains any code relevant to installation. In there, I have all my DB creation stuff (exported using mysqldump or whatever your weapon) and any shell scripts for creating directories (seeing as git doesn't let you keep empty directories in version control, a shell script that creates and chmods all dependent directories appropriately so that you don't have to do any of the hacktastic stuff I've seen recommended about the place!

Next, you'll probably come across issues with configuration. If you're working decentralised and, like me, have a local development server with different configuration to your live server, it's not entirely logical that git does /not/ like this. What I do is the following:

Create a "live" branch on remote origin (seeing as this config will be needed by everyone)
Create a "dev" branch on local with all your configuration stuff on it. Obviously work on "dev". Any work you do (on any branch really) gets merged back into "live" branch and pushed to the server - that way when you clone a repository on your live server, just switch to the live branch and pull and your changes down and your config will be ok. Git's also super helpful in that it won't bug you about config that you changed on your dev branch unless you change it frequently, so you're less likely to merge your dev config into live (but even if you do, it's really easy to undo anyway!)

That's a couple of things I use that I couldn't find something satisfactory on elsewhere. Stack Overflow is an otherwise invaluable resource for git (and anything else, really). Past all that, my knowledge of git is fairly standard, so if I can't help, you'll find someone on there who can.