2

What are the appropriate commands to create a remote "central" repo to use in a collaborative work environment for centralized workflow?

We are new to git and are starting from scratch to set up source control for a collaborative development.

There are lots of good resources here on stackoverflow, the git-scm site, and more. However, despite doing a lot of searches, I failed to find any useful info about the "from scratch" set up.

The best resource I found so far were the git book http://git-scm.com/book and Will's post Git for beginners: The definitive practical guide.

However I couldn't find anything about starting from scratch. Most posts assume that one starts from an existing remote repository or init an existing code base into git and then push it to some remote for collaboration.

I did the latter, but soon found myself or other developer not being able to push, not having access permissions or worse, screwing up something, so that I or him/her lost remote tracking on the pushed repo and not being able to get it back. One box (win xp) would work, but the other (win7) would not.

We use GitExtensions and initially I created the remote repo via "create remote bare repo". This resulted in the problems described. My latest attempt was to create my local repo, then clone it from local to remote as a public bare repo. So far this seems to work much better, i.e. no permissions problems, etc.

In hind-side, it looks like GitExtensions may have created a remote private repo rather than creating a repo that is capable of serving as the central collaboration repo, while using the clone repo dialog with selecting "public bare" repo seems to have created a repo that is configured to work for multi user collaboration.

Is this a GitExtensions or git problem? From what I read in the book, manuals or other git posts, I had assumed that I should be able to create a remote repo, push my local repo and use the remote to share my work or have others contribute. However that didn't seem to work. Only the cloning of my local repo to the remote location seems to now work as expected.

I am sure I missed something, but please tell me...

Community
  • 1
  • 1
MuOne
  • 29
  • 2
  • Are you sure you want to set this up yourself? Services like GitHub or Bitbucket exist precisely because setting up a proper git deamon with proper authentication, security and so on is hard work. I would reckon it's even harder on Windows. – Wander Nauta Apr 05 '14 at 08:37
  • We are developing inhouse, no public contributions. We are using the LAN, with a Windows 2003 server (remote, central repo), a win7 box, a win xp sp3 box and a win xp sp1 CNC machine. So, yes, we need to do it ourselves. – MuOne Apr 05 '14 at 08:51
  • @WanderNauta, if you dont understand the concept, then you cannot use these services properly anyway. And you should NEVER rely on a third party service. So you have to be able to set it up for yourself also. I think it is a really good question, but maybe it not belongs to SO but superuser or another site. – davidkonrad Apr 05 '14 at 08:53
  • @davidkonrad why another site? I came across SO as a good git resource. So posted here. – MuOne Apr 05 '14 at 09:01
  • @user3500478 Both companies I mentioned offer private repositories. If you absolutely don't want to host the code outside of your LAN, you could just put the bare repository on a shared network drive on your central machine, hook your other Windows boxes up, and have them do a 'local' clone from there. You'll not be able to access it from other locations, but that seems to be exactly what you're looking for. – Wander Nauta Apr 05 '14 at 09:04
  • 1
    hey @user3500478, because SO mainly is about programming. The twin-site http://superuser.com/ is perhaps a better place for such a question. – davidkonrad Apr 05 '14 at 09:05
  • @Wander Nauta. That was my question. How do I put the initial repo on then share. Create repo via GitExtensions caused problems. Clone my local to the remote seems to work. – MuOne Apr 05 '14 at 09:13
  • Just a `git init --bare` should do the trick: http://www.watkyn.com/blog/2011/09/22/Using-git-at-work-on-a-Windows-network-drive/ – Wander Nauta Apr 05 '14 at 09:14
  • I am a newby, not really familiar with the cmd line interface, using GitExtensions. But from what I can tell, git init --bare is what I expect GitExtensions did when I used it to create the remote bare repo. That's the approach that didn't work. – MuOne Apr 05 '14 at 09:37
  • @davidkonrad. I ended up here on SO, because there was so much discussion about git, git workflows and config. It seemed the right place to ask the question. – MuOne Apr 05 '14 at 09:56

1 Answers1

0

I couldn't find anything about starting from scratch

On the server side, assuming Windows, you can setup a server with Bonono Git Server.
The idea is to avoid anonymous access (since git:// protocol doesn't have authentication).

Having access to the centralized repos through a share file is called Local protocol.
Then a simple git init --bare arepo in that shared path is enough to "start from scratch".
But that doesn't provide any authentication or authorization.

Is this a GitExtensions or git problem?

On the client side, in case of errors (like a lost remote), I would advise to revert back to the command line (msysgit), and get more details that way.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @davidkonrad the question is about starting from scratch. Installing Bnonobo is a good way to quickly start from scratch and provide a centralized server for their repos. – VonC Apr 05 '14 at 09:08
  • 1
    I dont think an answer that only recommends _another_ third party solution is a satisfying answer. Maybe OP can use your answer, but I still think it should be migrated to superuser. – davidkonrad Apr 05 '14 at 09:11
  • Do I really need a git server? I have file acess to a public share from all LAN boxes. My latest attempt of cloning from local to remote seems to have set it up in a working manner. – MuOne Apr 05 '14 at 09:17
  • @MuOne file access (local protocol: http://git-scm.com/book/ch4-1.html#Local-Protocol) means no authentication, no authorization. That is not a proper way to manage centralized blessed repos. – VonC Apr 05 '14 at 09:19
  • @VonC. Hmm, double Auth..., may be that's what I missed? Can you recommend any links to read up about how the file access approach is problematic re authentication and authorization? We are a two developer-3box environment, so I thought we may be ok talking to each other. – MuOne Apr 05 '14 at 09:41
  • @MuOne authorization through filesystem could be enough in your case. The classic article on authorization vs. authentication is http://gitolite.com/gitolite/auth.html (in another setting, with another tool, but that does illustrate what a tool managing repos would have to cover) – VonC Apr 05 '14 at 09:45
  • @vonC Ok, read it. Wasn't very helpful to me though, a bit out of context. I guess I'll stick with "file system could be enough". Re protocol link in your original answer, that's one of he docs that I read as file system being perfectly alright for our phurposes. – MuOne Apr 05 '14 at 10:13
  • @MuOne then my answer stands. `git init --bare` to start from scratch, and msysgit to debug your commands. – VonC Apr 05 '14 at 10:14
  • @VonC, see my response to Wander Nauta. Git init --bare is what I assume GitExtensions did, which didn't work. Hence my post re what is the appropriate way. If git init --bare is indeed appropriate, the question is why does GitExtension "create" not work, but GitExtension "clone" does. Should I go and report a bug in GitExtensions? – MuOne Apr 05 '14 at 10:38
  • @MuOne GitExtensions is a local wrapper which, by default, will create a non-bare repo. Beside basic operations from your IDE, forget GitExtensions. Only the command-line is reliable. – VonC Apr 05 '14 at 10:41
  • @MuOne there is an option to set in order to create a bare one, though: http://git-extensions-documentation.readthedocs.org/en/latest/getting_started.html#create-new-repository "Initialize new repo" > "Central repository". But again, through command-line, you would already have finished the same task. – VonC Apr 05 '14 at 10:43
  • @VonC, both create repo and clone repo provide the option to create a bare repo. The difference was that the clone dialog stated "public", whereas the create dialog did not. So my suspicion is that "create" creates a remote private repo (writable by only me, e.g. For dictator workflows), while the "clone" creates a public (writable by anybody) repo. Is that a fair assumption? Considering I am new to git. What would be the cmd line cmds to check the differences? – MuOne Apr 05 '14 at 11:14
  • @MuOne nope, there is no authorization with local protocol (other than what the filesystem itself can offer, and on Windows, this is limited). So by default, any repo is writable by anyone. Git itself has no notion of authorization. Again, in doubt, a quick command in a command-line windows is much quicker. – VonC Apr 05 '14 at 11:17