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:to do one repo for every language that I translate my originary project in java?  It's this structure:/indipendentRepo1/ProjectJava/indipendentRepo2/ProjectClojure/indipendentRepo3/ProjectPythonto 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/ProjectPythonI tried to looking for some official guidelines for Git but I didn't find anything.
How I can organise a project in more programming languages in Git repos?
git;organization;code organization;porting;scm
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.