0

I would like to use git's decentralized workflow as daily programming source code version control. There are few programmers working in the team all equipped with Windows workstation. Each programmer may pull and push from each other's git repository.

What is the most easiest way to deploy a git gateway for the team? Http need to deploy web server that I am trying to avoid.

Chau Chee Yang
  • 18,422
  • 16
  • 68
  • 132
  • Duplicate of: [Git]How can I make my local repository available for git-pull? (http://stackoverflow.com/questions/978052/githow-can-i-make-my-local-repository-available-for-git-pull) – Chau Chee Yang Jun 25 '11 at 14:34

2 Answers2

1

Being in the same situation, I can recommend simply using SMB shares that contains repository. Repository clones are over several PCs, each one referencing other's remote. This is purely decentralized.

Remotes have URL registered in Git like this: //computer/share-name/repo

The only thing to care about is to open the share in Explorer before fetching or pulling. However remember not to push as they are non-bare repositories. Anyway you'd better have readonly access to other's share to avoid problems, so pushing wouldn't work.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
  • In this case, I need to open a share to allow other users accessing the repository. It is tedious setting share permissions for other programmers access to each computer. Is there any LDAP solution in Windows to set share permission? – Chau Chee Yang Jun 23 '11 at 13:03
  • Don't know about LDAP for Windows; but you can setup a group for the programmers, and you should have only to set access for this group. – CharlesB Jun 23 '11 at 13:10
0

+1 for using SMB shares.

We are using them extensively and they are very simple.

And an addition: just set up share with permanent mapping (My Computer -> Context menu -> Map network drive -> Reconnect at logon), so you have, say, Z:\ drive. Then you could just point git's remote to /z/my-repo.git/ and that's all. You could work with it anytime you like.

Also you could setup some local server with logical 'central' repository. Thus you will not need to setup each dev's box with many shares etc. When you want to share - just push changes to central server. In small team (less than 10-15 developers) you could go away with just convention about when you could base your work on someone else's branch in central repo or not (so that you won't have problems with forces pushes, rebases, rewriting history etc). In larger teams or distributed team you could setup fetch rules about which remote branches should be tracked/fetched automatically ('public' shared branches where history rewriting is not welcome) and which should be fetched only by explicit demand ('private' branches where developers could share work with peers and make an arrangements how to deal with branches individually).

Ivan Danilov
  • 14,287
  • 6
  • 48
  • 66