I agree with @justin8 that one repo per workspace is a very cool experience.
Creating a workspace for a repo is like having a laptop just for working on a specific project, and then switching laptops to work on another workspace. Which is awesome, and Cloud9 lets you do that with a click of a button.
In some scenarios, however, you might want to work on multiple projects at the same time. For example, you’re developing a web service, and a command line app that need to talk with one another. Although they are part of the same project, they might have separate repositories, and different people working on them.
What’s the best way to proceed in that scenario?
You can still have one workspace per repo, and just open each in a new tab, which is almost instant, and allows you to context switch instantly. However, you might not prefer that.
So, coming to how to set up a Cloud9 workspace for multiple repos. Here are some considerations:
- Don’t create a workspace by cloning a repo. That will make the
~/workspace folder contain the repository you cloned. Anything you clone within a subdirectory will be added to the main repo.
- Create a workspace without cloning, preferably using the ‘Custom’ type, so you have an almost empty
- Now, within the
~/workspace folder, you can clone git repositories and each will have their own folder
With the workspace-per-repo setup, you never have to worry about which git repository you’re committing to, but in the multiple-repo-per-workspace setup, you actually do. Say you have the following setup:
If you run
git ... on
~/workspace, you’ll get an error as
~/workspace doesn’t have a git repo. Going to
repoA will allow you to modify the repository there, and going to
repoB will modify a different repository. So, you’ll have to be careful about where you’re committing / pushing etc.
This is also a very good reason for going for the workspace-per-repo setup, as it frees you from thinking about this, and also just works.
I hope this helps.