How do I organize my Git repo

I’m facing the following problem and don’t have an answer to it:

We have a repo that was cloned from an SVN repo. The project stored in that repo is something like a platform software that gets used by various projects. The structure of the repo is like this:

  • How to 'git pull' without SSH -or- password?
  • GIT: how do i do a partial merge from one branch to another one?
  • Run git pull over all subdirectories
  • Git: trouble with setting up daemon, trouble with git clone
  • Using IntelliJ IDEA ignoring unversioned files aren't added to .gitignore
  • Is it safe to use the same ignores file for Git, Mercurial, and Bazaar?
  • platform
      |- core
      |- additional
    

    The structure of that repo cannot be changed for some reasons. Both, core and additional contain data that are part of that platform.

    If a project wants to use the platform and add some functionality, it creates a new folder under additional containing the sources and adds a header for that functionality to additional/includes

    Currently, we simply branch off new projects from master and everything goes into the same repo. This leads to a branch inflation and my (central) repo grows more and more because all of the commits being made in the single projects go to the central repo (my colleagues are used to SVN, so they push nearly after each commit — just to be sure…).

    First I had in mind were submodules: keep platform as a submodule under a superproject (called super) and then go to super/platform/additional/mystuff, create the sources there and add them to super. But this obviously doesn’t work because the files are inside the platform submodule.

    Is there any better way to organize my repo, so that:

    • users of the platform are able to update their working copy from the central repo
    • AND users of the platform are able to apply bug fixes to the repo of platform
    • AND the projects using platform don’t mess up the repo of platform?

    EDIT 1: Highly coupled git submodules covers quite a bit of the scenario I’m in: tightly coupled stuff, me the only one knowing a bit more than absolute basics of git, “Most of the developers have only a very cursory knowledge of git”. Perfect match!


    EDIT 2:
    While the answer from Michael looks promising, I think that it’s a bit too complex to use. I’m looking for some really simple thing that doesn’t need that much interaction.

  • My Android Project has are now Colored Red after Experimenting with CVS in android studio
  • Does EGit “Revert Commit” permanently delete the original commit?
  • How to solve .xib file conflicts in Git
  • How can I tell Git to ignore certain branches when fetching/pulling?
  • Integration between any git repository and versionone commitstream
  • How to make TortoiseSVN / TortoiseGit show the executed command?
  • One Solution collect form web for “How do I organize my Git repo”

    I found your usage of master a bit confusing as I never knew
    whether you meant the platform repository as a whole or just its
    master branch.

    My solution to this would be the following:

    • You have one central repository for the platform.
    • You have one central repository per project.
    • Every developer has his/her own repository local.

    The central platform repository

    This is where only the platform code goes to. Use e.g. your
    existing repo as a starting point here.

    The central project repository

    This is a clone of the platform repository and keeps all the code
    of a project. Init it with

    $ git clone --bare /path/to/platform
    

    The developer’s local repository

    Init

    You, as a developer, start by cloning the project repository.

    $ git clone /path/to/project
    

    Making changes to the project

    Now, make your changes, commit them and push them to the projects
    bare repo.

    $ editor some-file
    $ git add -p some-file
    $ git commit
    $ git push
    

    Pull changes made by other developers to the projects bare repo
    by using git pull.

    Making changes to the platform

    As you also want to make changes to the platform itself, you also
    need a way to access the platform repo. So you add it as a
    remote repo to your local repo:

    $ git remote add platform /path/to/platform
    $ git fetch platform
    

    As you can see now with git branch -a, your local repo knows
    about the platform. Now you want to make some changes to the
    platform. First you create a local branch central which is a
    clone of the master branch of the platform repo:

    $ git checkout -b central platform/master
    

    You can always check which branch you’re on by using git branch
    or git status. Now you make your changes and commit them (to
    central, where your on). As central is connected to
    platform/master (checkout cat .git/config) you can push your
    changes to the platform repo by simply using git push. Also
    git pull works without any other arguments.

    Use git checkout master and git checkout central to change
    between your branches.

    Get a new platform version into your project

    Note: You need to have done the work from the previous section.

    First change to your platform branch and pull in the new version
    of the platform:

    $ git checkout central
    $ git pull
    

    Now go back to your project branch and merge the changes made in
    the platform into your project branch.

    $ git checkout master
    $ git merge central
    

    If a conflict occurs, something like this happens:

    $ git merge central
    Auto-merging index.html
    CONFLICT (content): Merge conflict in index.html
    Automatic merge failed; fix conflicts and then commit the result.
    

    Open the files with the conflicts, resolve them, add them to the
    staging area and commit the merge:

    $ editor index.html
    $ git add index.html
    $ git commit
    

    Now push your changes to the project’s bare repo:

    $ git push
    

    More about merge conflicts: Pro Git: Basic Merge Conflicts

    If you do not want to change the platforms repo, but merge
    changes from there into your project use

    $ git remote add platform /path/to/platform
    $ git fetch platform
    $ git merge platform/master
    

    The git remote add is only needed the first time you merge.
    The other two are always required.


    The part about merging is based on the Pro Git Book which is
    licensed under cc-by-sa. All other content of this post may be
    considered public domain.

    Git Baby is a git and github fan, let's start git clone.