0

I am trying to figure out if is possible to have on the server cloned more that one branches from the same repository. Those branches are cloned into different folders through ssh.

Let's say:

feature/feature1 -> C:\feature1 (user1)
feature/feature2 -> C:\feature2 (user2)
feature/feature3 -> C:\feature3 (user3)
feature/feature4 -> C:\feature4 (user4)

The goal is to access every folder by different user at the same time (more different checkouts at the same time are needed). Pulls, pushes, commits are in parallel proces ...

Does this solution make sense? We need to work on server as our system has access just there. There is not access to our local PCs.

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
MIchal Skoda
  • 47
  • 5
  • 1
    In your case, checking out a worktree would look like : `git worktree add C:\feature1 feature/feature1` – LeGEC Oct 04 '21 at 09:18
  • 2
    I first marked this question as a duplicate of : [Multiple working directories with git](https://stackoverflow.com/questions/6270193/multiple-working-directories-with-git) ; while `git worktree` is the go-to command to have several local checkouts of the same repo, it doesn't deal with multi account access to the same local repo. – LeGEC Oct 04 '21 at 09:21
  • 1
    @LeGEC Group access can be configured using [`core.sharedRepository`](https://stackoverflow.com/a/69193032/7976758). – phd Oct 04 '21 at 11:09
  • @phd : great answer :) do you know if it also works correctly on Windows ? – LeGEC Oct 04 '21 at 12:21
  • @LeGEC Nop, no idea, sorry. – phd Oct 04 '21 at 13:14
  • I don't think the shared repository stuff works on Windows. – torek Oct 04 '21 at 19:57

1 Answers1

0

The git worktree method described in comments will work on a Unix/Linux system, but probably not on Windows if your different users have different accounts (which they should, for sanity if nothing else). It has some drawbacks: in particular, while each working tree gets its own index, all the working trees share one single underlying repository, which means that Git commands that must write to the repository have to wait while someone else has the repository databases busy. How disruptive this might be in practice depends on how your users would use this.

It's usually a much better idea to give each user their own full clone, even on a shared server, and even if it's a Unix/Linux system. They can then push to, and fetch from, one more clone on that shared server, that you designate as the "source of truth". There is only one drawback to this method of sharing, which is that each clone occupies its own extra disk space. However, this tends to be minor: when cloning a local repository locally, using file-oriented "URLs":

git clone /path/to/source-of-truth.git work/my-clone

Git will, to the extent possible, use "hard links" to files to save space. These hard links work quite well, although the links "break apart" over time (as files get updated) and gradually the clones wind up taking more and more space. This means that every once in a while—say, once a month or once a year or so, depending on activity—it may be helpful for space purposes to have your users-on-the-shared-server delete their clones and re-clone at a time that's convenient for them. This will re-establish complete sharing.

(Of course, disk space is cheap these days, and the right way to handle this on a modern Linux server is probably to set up a ZFS pool with, say, a bunch of 8 or 12TB drives in a RAIDZ1 or RAIDZ2 configuration to get many terabytes of usable storage at around $30 per terabyte, even counting overhead and the cost of cabling and so on. You'll probably pay more for some high end Intel CPU than you do for all the drives put together.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • not sure if i get your point but every user has his own clone of own branch of the the same repository. So if i understand it should work ... – MIchal Skoda Oct 05 '21 at 08:49
  • @MIchalSkoda: a clone *is* a repository. You don't have a "clone of a branch", you have a clone of a *repository*. If every user has their own clone, you have N clones, each of which is independent, and there's no issue in the first place. You described a setup where you have *one* repository—one "clone" in other words—and N users each using a separate branch in that one repository. – torek Oct 05 '21 at 08:55