0

The situation is this:

We have a git repo on some server with one branch on it, let’s assume it’s master. We clone that repo to our own machines and do things on it. Each of us have our own local branches, but when we push to the server, we always merge/rebase our local changes onto master first, and then push to the server.

Everything is fine.

Now some other guys want to join the development. Therefore we decide to share our repo with them, except that one particular directory. What we want is some kind of mechanism, with which we can develop the project as usual (one branch on server, local branches for convenience), but when that “other guys” clone the project (maybe with some other clone command, or whatever proper command provided by the mechanism, we’ll teach them the command), they see all the content except that particular directory (or they can see the dir, but it’s empty, or they don’t have access), and they can also push their changes to the server, and have their own local branches, etc.

What’s the best way to achieve this? I don’t mind having multiple repos on the server.

I’ve been looking into submodule, and did some tests. The thing I don’t like about submodule is that I have to go into the submodule dir and add/commit/push etc (er… right?). Also I’m not sure how submodule will fit into our local branches workflow. Any suggestion are welcome.

MetroWind
  • 541
  • 4
  • 16
  • Why shouldn't they be able to see that directory or its contents? If it contains access tokens/ sensitive information, you should use environment variables external to the repo – jshawl Jul 18 '14 at 19:05
  • @jessh: because the author of that directory don’t want others (except us) to see his code. That dir is part of this project, therefore we prefer to put it inside the project and do development as a whole. – MetroWind Jul 18 '14 at 19:28

2 Answers2

0

You may want to look into a .gitignore file for your project: http://git-scm.com/docs/gitignore

Bob Paulin
  • 1,088
  • 8
  • 13
  • Doesn’t that stops us from developing in that dir also? – MetroWind Jul 18 '14 at 18:16
  • It will exclude that directory from commits. If you are expecting to still be able to develop in that directory I would stick with the submodule approach. See http://stackoverflow.com/questions/7912022/do-you-ignore-a-git-submodule-in-your-gitignore-or-commit-it-to-your-repo – Bob Paulin Jul 18 '14 at 18:21
0

First, obviously you can not put those code in the same repo if you just think about how git works, so you definitely need multiple repositories.

And from what you said, I could assume that without that directory X, your project will also able to work, then it's definitely a good idea to separete it. Then the problem is how can you organize your repo.

Submodule feature just saves a sha1sum reference to a commit in another repository, which is saved as a file named .gitmodules in the root directory. Everytime you commit to submodule, the .gitmodules file will be changed just like a ordinary file in the root repo, and then you need commit at the root repo to update the reference of submodule. One can also work without execute submodule init after clone.

There're quite a lot real world examples of how to use submodule.

https://github.com/owncloud/core/ is a repo with 1 submodule.

https://qt.gitorious.org/qt/qt5/ has a script that let developer optionally enable some submodule.

Depending on your project structure, you can organize one root repo with only skeleton with a lot of submodules, like Qt; or a main repo with several submodules that might be optional or independent to the main project.

After you decide the structure, then you might want to look at git filter-branch about how to separete directory into different repo but also reserve the history.

csslayer
  • 317
  • 2
  • 9
  • Thank your for your detailed answer. The Qt5 repo looks interesting. I’ll see if I can learn something from it. If we can get over submodule’s trouble of “having to go into each dir and commit separately”, I think Qt5 makes a good case. – MetroWind Jul 19 '14 at 02:49