How to set up an existing Git client repository (connected to a remote) AS a Git server repository (i.e., another repository's remote) on Windows?

Question

I have an existing Git repository, with working copy, connected to a GitHub remote repository (my local repository is on Windows).

I would now like to allow another developer to clone my local repository and connect to it as its remote repository.

Is this possible?

I have installed GitStack for Windows, but I see only the possibility of creating a new repository - not setting up an existing local repository to be used as a remote repository for another repository.

If this is not possible, is there some way I can set up my Git infrastructure so that I can achieve the same end - i.e., so that when the other developer commits, I do not have to do anything and those commits appear in my existing Git repository?

Answer 1

Yes, a regular Git repository (non-bare, with a working copy) can be cloned.

For example, assume your existing repository exists at C:\my-repo\. You can clone it to C:\my-repo2\ like this:

cd /d c:\
git clone my-repo my-repo2

Cloning it from another machine is a bit different, since you need to open up a network path to your existing repository. On a Linux system I would recommend enabling SSH or using git instaweb. Of course, both of these can work on Windows, but setting them up isn't nearly as easy.

Looking through the documentation for GitStack, you probably want to follow these instructions for importing an existing repository. Point GitStack at your existing clone and you should be good to go.

A note on pushing

As Hashem Qolami points out, by default the non-bare repository will not accept a push to its active (checked-out) branch. You have a few options here.

• Read about receive.denyCurrentBranch in git help config and decide whether you want to enable pushes to the checked out branch. I wouldn't recommend changing this setting, but it should be mentioned as an option.
• Have downstream developers push to a different set of branches. For example, decide that downstream developers will push to branches called developer-name/branch-name. Then merge the branches in the upstream repository.
• Instead of having downstream developers push into the upstream repository, enable incoming Git connections to downstream machines as well and fetch (or pull) downstream changes into the upstream repository.