We are four social scientists working on a dataset that is in a secure server accessible via remote desktop. We have a shared folder where we put our code and datasets:


Right now all we have done is to:

git init
git add --a
git commit

At the root of our shared folder. We have also edited a .gitignore file to keep git from tracking images and non-plain text files.

This way, whenever one of us edits a file we go:

git add editedFile.r
git commit

Which can erase the changes if the previous person who edited the same file didn't stage and commit it. Not all of us are fully conversant in git and it is likely that the more skilled will have to periodically check the status of files, stage, and commit them for the ones who don't git yet.

Each of us also has our own private folder on the same servers. We potentially could have each our own local repository in our private folders, and treat the shared folder as a remote. Then we would:

git pull
git add editedFile.r
git commit
git push

As we go by our workday.

Which one would work better for the situation described: fork and pull (each one with our own repository and the shared as a remote) or all work on the same repo in the shared folder?

  • I suggest that you study some git tutorials and use it in the standard way. – user2768 Aug 5 '19 at 13:29
  • Is the standard way the usual work -> stage -> commit -> work? I have done git tutorials and read the Pro Git book. Have been using it for my own projects alone, but it is the first time in the setting described above. – Kenji Aug 5 '19 at 13:32
  • 1
    The standard usage revolves around different developers working on different systems and using git to resolve conflicts. It sounds like you're all working on the same system. Is that correct? – pip install frisbee Aug 5 '19 at 13:34
  • @pipinstallfrisbee yeah, we all work on the same system. Mostly r and python scripts for data wrangling and analysis. – Kenji Aug 5 '19 at 13:36
  • 1
    Looks like this question is better suited for another SE community... – Scientist Aug 5 '19 at 16:48

I pretty much agree that you've got two options:

Work as is, all in the same directory on the same system.

There are a lot of problems with this approach.

  • If multiple people are working at the same time modifying source files you'll step on each other's feet a lot. Two people can't edit the same file at the same time. You'll deal with annoying "that file is in use by another process" messages all the time.
  • Someone might make a change that affects the behavior of a function and it'll come as a surprise to someone else.

On the other hand, the issues you'll run into are fairly easy to recognize and plan around. If you all aren't familiar with Git, and expect to be making actual code changes fairly infrequently, the cons aren't too big of an issue.

I would avoid this at all costs. I've worked on projects before where multiple people were working on the same files in the same directory on a remote server and it's awful. Words almost cannot describe the frustration that it leads to.

Multiple versions of the repository

Set up the filesystem to look like:


Each user should have a directory that contains it's own clone of the repository. This lets you avoid stepping on each other's toes when working at the same time, and lets you emulate a "normal" git environment.

From there it's just business as normal, and as long as y'all can overcome the initial learning curve it'll work out much better than if you're all working in the same space.


I've been through similar in a small research group. As you identified in your second option, to make git work usefully you you need to be working on your own copies of the repo. These might be on your own PCs or on a network drive, but there needs to be only one person using each copy.

You then need a way to keep everybody up to date.

  • The minimum for this is people shouting "hey, I committed something, everybody pull from me". This is probably not going to scale well.
  • The "ideal" is probably using something like github, Bitbucket or gitlab, either in the cloud or locally hosted, as a central repo that everybody pushes to and pulls from. If you're academic then private repositories are free from the major cloud providers but sensitive data, institutional policies, or some other reason might prevent you from using them.
  • If this isn't feasible for whatever reason, you can set up a similar central repo on a network drive - but this wants to be a "bare" repository, where there's only the behind-the-scenes .git structure and no "working copy". Otherwise if somebody edits that working copy, you'll get in a mess. Best to consult a git expert on how to set this up.

If your team aren't familiar with git, then this is not a quick or easy thing to set up; and more importantly, to make it work usefully your team needs to become familiar with git basics and be prepared to put time and effort into using it right. This isn't going to work unless everybody is "on board".

  • there needs to be only one person using each copy, why? – user2768 Aug 6 '19 at 7:11
  • @user2768 well, multiple people using one repo, with good communications, can still use git to provide them with a version history. But they are going to have to deal manually with making sure they don't overwrite each others' work, etc., just the same as if they weren't using a VCS at all. If multiple people are working from the same copy of the repo they are missing out on most of the benefits. – Flyto Aug 6 '19 at 17:11
  • It isn't true that: they are going to have to deal manually with making sure they don't overwrite each others' work. That's the problem that VCS solves. Nor is it true that: If multiple people are working from the same copy of the repo they are missing out on most of the benefits. VCS provide benefits in such situations. – user2768 Aug 7 '19 at 7:05
  • @user2768 how does git solve that problem, if they are all working in the same copy of the repo? – Flyto Aug 7 '19 at 14:48
  • Multiple edits are automatically merged by the VCS (except when conflicts arise). – user2768 Aug 7 '19 at 14:50

(The question has been edited twice since this answer was written, it may no longer be relevant.)

You want to use git and either:

clone[ a shared folder] to our own private folders


all work on the files in [the shared folder]

For the former, you needn't use git, so surely the latter is the only option that makes sense.

The advantage of keeping all the code in one place...

All the code is in one place (your git repository) regardless of which option you pick.

...the ones who don't git won't have to bother learning it

It is hardly complicated to learn:

  • git pull (before you start work)
  • git commit (to locally backup)
  • git push (to share)
  • 1
    Could you elaborate on the first option not making sense? Wouldn't clone[a shared folder] benefit from git's version tracking and push/pull functionalities? – Kenji Aug 5 '19 at 13:00
  • To collaborate, you want one copy of your project, not n-distinct copies, where n is the number of collaborators. – user2768 Aug 5 '19 at 13:03
  • I edited the question to reflect what I had in mind. I think I didn't use the correct lingo to describe the second option. We actually were thinking about treating the shared folder as a remote and pushing to it from our own folders. – Kenji Aug 5 '19 at 13:17
  • @Kenji I'm now more confused as to what it is you want to know... – user2768 Aug 5 '19 at 13:27
  • 1
    @Anyon There's no suggestion of forking/merging in the question and I doubt that's what the OP has in mind. – user2768 Aug 5 '19 at 13:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.