4

At work I'm using Java, but I'm planning to study some other programming languages as Python or Clojure.

I'm thinking of coding one project in Java in my Git repository and, during my study, coding the same functionality in Python or Clojure.

Because it will be a project without an effective value at work and by a personal goal, do you think that is better:

  1. to do one repo for every language that I "translate" my originary project in java? It's this structure:

    • /indipendentRepo1/ProjectJava
    • /indipendentRepo2/ProjectClojure
    • /indipendentRepo3/ProjectPython

  2. to do one single repo for this project in general and start a branch for every language? It's this structure

    • /singleRepo/branch/ProjectJava
    • /singleRepo/branch/ProjectClojure
    • /singleRepo/branch/ProjectPython

I tried to looking for some "official" guidelines for Git but I didn't find anything.

jonrsharpe
  • 1,318
  • 2
  • 12
  • 17
alepuzio
  • 341
  • 4
  • 15
  • 2
    What makes you think there are official guidelines for organizing your projects? I think it is more likely that the organizational structure of your projects is entirely up to you. – Robert Harvey Jan 29 '17 at 19:27
  • I tought I'm not the first persona who has this doubt: generally, when some people have the some problem, it's possible to find some guidelines or decisions and their explications or motivations. I though that the explication of semantics of branch in GIT could give me some intuitions... – alepuzio Jan 29 '17 at 19:40

2 Answers2

4

This is very personal and depends on your style of maintaining your code and how you work with code repositories.

Then again there are recommended "best practices", that are there for a pretty good reason.

You can do either one approach and it won't be "wrong" in the sense that as you stated, this is going to be a personal project and no other people will contribute. But please consider the services that a code repository offers beyond "save the state today and maybe I will want to get back to it someday"...

First of all, when you make a commit to a repo, you are saying "I made a change and this is what changed; this other thing was affected/is added/is gone". So if you change your project in one language, in the repository hold all projects at once the history will carry that change semantically for all projects, even though the other languages didn't change. If you are using the commit history to track activity, it gets harder to separate the projects even when they are on separate branch.

The only way I would consider keeping separate projects on the same repo, is if I wanted to track the implementation of the same feature across all projects together - but in this case the repo does not help you to enforce that, only your own discipline to follow through and implement the feature you just committed in one language to the next one, before you work on something new in the current branch.

Then consider what branches are for - to try out something without breaking the currently working software. Your use of branches in example 2 is contrary to that. Although easily recoverable, it will incredibly frustrating when you keep trying at some later point to merge branch Java-feature-Y into branch ProjectClojure instead of the other one, just because you went late to bed and forgot which branch you worked on late last night ;-)

This is my personal experience here, but I have never had more than one project per Git repo ever since I started working with it. Even while I still used Subversion, I had multiple projects in the same repository at the very beginning only.

Todor Todorov
  • 86
  • 3
2

If it is the same project, it makes sense to have all "versions" of it (in different languages) in the same repository, so that you will be able to easily track changes in each version (a subdirectory of your main repository per language I would think, not a branch in the git sense).

For example, if you implement feature X, you will be able to do a single commit for feature X in language L1, L2 and L3.

A single repository will also make your life simpler for cloning, moving, backuping, etc…

Patrick Mevzek
  • 189
  • 1
  • 1
  • 12