When I setup git in my company I ran into many issues. I was moving all my projects from a Subversion environment to a GIT environment. I already knew that GIT was a lot more flexible than Subversion and there were many possible ways of setting up the work flow. Being the first time I ran into some issues and I have to change the way we worked a couple of times.
My first setup
The project I was working on at the time had two developers, including my self. I opted for setting up a our work flow as a decentralized environment. The problem with this approach was that we were used to a centralized environment. It wasn't so much of an issue, but actually an annoyance. After some reading we decided to place a centralized bare repository some where in the /var/lib/project_name directory. It was a work flow that we were more used.
After a couple of days working with it, we started having some permission issues in my local copy. I looked inside my .git directory and found files owned by the other developer. I quickly ran a "sudo chown -R myusername:myusername .git" to claim ownership of my files and fixed the issue. I thought it was strange at the moment, but I didn't put to much thought into it.
Later that same day, the other developer was having the same issues. She was not able to perform certain tasks because the files where owned by me. This time I looked a little closer. I compared the files that had the issue with "ls -hli". I used the "-i" switch to show the file inode numbers. I quickly found that her files and my files where the same. I discover that Git was actually not coping its internal files, but it was creating hard links of the files create by the other developer.
I did some reading on-line about the issue and I found that Git creates hard links for performance purposes. I was not a git expert and I wasn't sure how to turn off this feature, I thought about a workaround. I already know that git worked over SSH and there was no way to create hard links over SSH. I moved the git repository to it's own *nix account and had everybody clone the repository from this account.
The solution was elegant!, and it also had the added feature of being able to clone the project outside our development environment.
This is what I did. All commands that start with # I ran as root, and commands that start with $ are ran as a regular user.
Create a *nix account for the git user as root:
# useradd git -m
Create a password, this step is optional since I use SSH Keys, it's only temporary.
# passwd git
// create an empty bare repository in git's home directory
# su - git
# mkdir project_name.git
# cd project_name.git
# git init --bare
I ran these commands as a regular user:
// create project
$ mkdir project_name
$ cd project_name
$ vi some_file.txt
$ git init
$ git add .
$ git commit -m "STARTING PROJECT"
// push to central repository
$ git remote add origin git@localhost:project_name$ git push origin master
Now it's was up to the other developer to clone the central repository.
$ git clone git@localhost:project_name
If you don't want to type the password for the git account every time you push a commit or you don't want to distribute the password. You can install your SSH keys on the git account.
I you have not already don't so, generate your ssh keys. You can leave the default key file and type your security pass phrase. If you don't want to ever type the pass phrase, just leave it empty.
$ ssh-keygen$ ssh-copy-id -i ~/.ssh/id_rsa.pub git@localhost
That's it, now you can continue your live with your regular pulls and pushes to the central repository.