How can I organize personal Git repositories?

Question

I'm in the process of setting up a GitHub account with the plan of making a pair of libraries I developed as parts of some recent iOS projects freely available for other iOS devs to use.

I don't currently have off-site backup for most of my code, so as part of this, I originally thought I would upload all of my personal projects, or at least all of my iOS projects, to a private GitHub-hosted repository. However, I have a lot of projects sitting around, many of which are fairly low-value (i.e., adapted from books and written for the learning experience). Not only does GitHub charge by the private repository, it doesn't seem to have any way of organizing repositories hierarchically.

Is there something I'm missing that would allow me to use a git repository with a hierarchy and check out pieces as I need them / work with them, the way I currently do with SVN?

Does GitHub (or a competitor, like BitBucket) have some project organization features that I'm missing?

Failing that, what's the generally accepted "Git way" of handling this situation (discard projects not intended for release, store them offline, bundle them together somehow, etc., etc.)?

As far as I can tell, my options are:

1. Put libraries on GitHub, continue hosting my own SVN for all other projects, use a non-VCS solution for off-site backup (blech),
2. Put libraries and software I plan to release on GitHub (as public and private, respectively), continue hosting my own SVN for projects I don't care about as much and am only likely to revisit to refresh my memory on how to implement XYZ, decide that I'm willing to write them off if my house implodes (double blech),
3. Put everything on [GitHub and/or BitBucket], deal with having some ridiculous number of repositories by searching for what I need / maintaining some offline set of pointers into my [GitHub and/or BitBucket] account (triple blech)

Answer 1

bitbucket.org lets you create unlimited private repos.

Git does not let you check out just some pieces of code. So you would need to create a repo for each project, or deal with cloning all the projects. In reality I don't see a problem with putting all our small projects in a single repo. You clone it once and you are done.

With Git you don't ever have to "checkout" the code again unless you blow away your local repo or move to another machine. You'll just synchronize all your changes.

I have a simular issue with a large number of repositories. The reason I cannot store them all in a single repository is that I need to branch different versions off of each and every repository. It is very difficult to manage.

Answer 2

Short answer ...

My suggestion: Start with public accounts on GitHub and/or Bitbucket (other?). Throw up a few public projects and start using the tools/interfaces. Once you've got a feel for the services, then you should have a grasp as to what the limitations, advantages and disadvantages of each service are. From there, you should be able to choose the best path to version control enlightenment. :)

---

Long answer ...

I don't currently have off-site backup for most of my code, so as part of this, I originally thought I would upload all of my personal projects, or at least all of my iOS projects, to a private GitHub-hosted repository. However, I have a lot of projects sitting around, many of which are fairly low-value (i.e., adapted from books and written for the learning experience).

Have you considered installing your own Git client? If you're already paying for web hosting, then it might make sense to use that host for your own Git setup.

For example, my host is WebFaction (no affiliation):

Installing the Git Web Application

Heading this route might allow you to save some $$$, esp. if you're already paying for hosting.

Not only does GitHub charge by the private repository,

Just to clarify for others (again, no business affiliation to GitHub or BitBucket):

GitHub: Plans & Pricing

• $7/mo. for up to 5 private repositories, unlimited everything else.
• $12/mo. for up to 10 private repositories, unlimited everything else.
• $12/mo. for up to 20 private repositories, unlimited everything else.

Note that "Business Plans" pricing is different.

Pricing for Git and Mercurial repo hosting for Bitbucket by Atlassian

As stated in by Andrew in the other answer, Bitbucket touts unlimited private repos.

• 5 users: Free
• 10 users: $10/mo.
• 25 users: $25/mo.
• 50 users: $50/mo.
• 100 users: $100/mo.
• Unlimited $200/mo.

it doesn't seem to have any way of organizing repositories hierarchically.

Not sure exactly what you mean by "hierarchically" (probably because I'm not familiar with SVN).

I'm not sure if this would help, but you could look at this comparison table to see how the commands compare/differ:

• Hyperpolyglot: Version Control

Is there something I'm missing that would allow me to use a git repository with a hierarchy and check out pieces as I need them / work with them, the way I currently do with SVN?

Branching?

• A successful Git branching model (a.k.a., git-flow)
• GitHub Blog: GitHub Flow in the Browser

Does GitHub (or a competitor, like BitBucket) have some project organization features that I'm missing?

Not sure if this will help, but you might take a look at:

• GUI Clients

Git comes with built-in GUI tools for committing (git-gui) and browsing (gitk), but there are several third-party tools for users looking for platform-specific experience.

... again, not sure if any of those tools could help you to get a feel for what's possible.

To be clear, I'm not sure of you Git skill level ... if you're new to Git/GitHub, using a GUI might be a quick/easy way for you to get a feel for things. I personally like using the official GitHub for Mac/Windows apps.

Failing that, what's the generally accepted "git way" of handling this situation (discard projects not intended for release, store them offline, bundle them together somehow, etc., etc.)?

If I were you, I'd be using repositories.

How many private repositories do you need?

If you want to use GitHub, one solution might be to get the cheapest plan and utilize a few private repos to hold all of your test/non-public code. You could just use a folder structure on your main branch to maintain a hierarchical structure, or you could use multiple branches to keep things more separate.

Tip: If you're using a more recent version of Git, you can pull specific branches using git clone -b mybranch --single-branch git://sub.domain.com/repo.git:

• Clone only one branch
• How to clone a single branch in git?

I have to warn you though, using branches to organize code (like folders) isn't really the best way to do things (though, there's nothing that says you can't head this route).

(Seem my answer here for related info in regards to GitHub branches.)

Again, I think multiple repos are the way to go.

You might ask yourself if your code is really needing to be private; is it possible that you could go public with said code without any repercussions?

Put libraries on GitHub, continue hosting my own SVN for all other projects, use a non-VCS solution for off-site backup (blech),

If you head this route, Dropbox (or similar) might be a good way to get some form of version control and syncing for your off-site backup.

Put libraries and software I plan to release on GitHub (as public and private, respectively), continue hosting my own SVN for projects I don't care about as much and am only likely to revisit to refresh my memory on how to implement XYZ, decide that I'm willing to write them off if my house implodes (double blech),

This takes me back to the question "Do you already pay for hosting? If so, you could install your own Git host"; the advantage being, you could have all source code under the Git umbrella, even if it's not all on the same host (i.e., use GitHub for the public stuff you want to show off).

Put everything on [GitHub and/or BitBucket], deal with having some ridiculous number of repositories by searching for what I need / maintaining some offline set of pointers into my [GitHub and/or BitBucket] account (triple blech)

---> See my short answer above. ^^^^^^

Answer 3

Here's what I do:

• Put standalone projects you wish to make public in separate GitHub repos. Since GitHub is at the moment the de facto place to share code, that will make your projects more discoverable/easier to fork.
• For any projects you wish to keep private, put them in private repos hosted by your provider of choice. As already mentioned, Bitbucket is a good choice for this as it allows for unlimited private repos.

• Put all other code into a "junk" repo. This can include code used for learning and testing as well as small snippets that aren't really part of a project. As long as there's no reason to keep this private, you can host this repo on GitHub too.

  In addition to all the usual advantages of version control (that you already have with SVN), now your code is backed up online. In case any of your junk code turns into a project you can just spin it off into its own repo.

  You could put this code into separate repos or use something fancy like git submodules or subtrees, but I find it's easiest to just keep it all in one repo and organize it using folders. It's much simpler and git is fast enough that the size of the repo shouldn't be an issue.

  • For example, here's mine: https://github.com/bmaupin/junkpile
  • A few others:
    • https://github.com/voltagex/junkcode
    • https://github.com/jivoi/junk
    • https://github.com/infnty/junkyard

Answer 4

One possible technique would be to use branches.

Branches in a git repo are just pointers to commits, they don't have to be related to each other in any way. So you could create a "minorprojects" repo on the hosting service and then use a branch in that repo for each project. If a minor project grows you can easilly move the branch to it's own repo.

Locally you can either keep the branches in seperate local repos (there does not have to be a 1:1 mapping between local and remote repos) or have a single local repo and use git worktree to maintain multiple working trees. Personally I suspect the first approach is less error prone.