CODEWITHSUNDEEP
git
user1790399
user1790399

Reputation: 321

How to set up a series of related projects on git

I'm new to git, and am setting up a repository for a number crunching application I'm involved in developing.

The basic idea is to eventually have a folder structure with something like

|-- Code for application A
  |-- header
  |-- src
  |-- objdir

What I'd like to be able to do is support a Windows, Linux and Mac version of the application. The core code does the same thing across the platforms, but right now I've had to reorganize the project to be:

Application A
|-- Windows
  |-- Code for application A
      |-- header
      |-- src
      |-- objdir
  |-- Windows specific code
|-- Mac
  |-- Code for application A
      |-- header
      |-- src
      |-- objdir
  |-- Mac specific code
|-- Linux
  |-- Code for application A
      |-- header
      |-- src
      |-- objdir
  |-- Linux specific code

The work flow of my setting is such that everyone uses different OSes, so often we would work on say the material in the Windows folder and experiment with the stuff in the "Code for application A" folder, but at least initially would like to do so independently of the stuff in the other folders. If the changes in the "Code for application A" that result from messing around with the windows version seem viable, then we'd port that solution to the other folders (e.g., "Linux/Code for application A").

I'm wondering what would be the most natural way to to go about setting all this up in a single repository using git.

I think keeping separate repositories for each version will get unwieldy, and it would be nice to maintain some sort of indication that these are all just different versions of the same application A.

We used to use subversion and abused branches to get this to work (allowing us to have different working directories for each version), but now that the decision's been made to migrate to git, treating the different versions as branches seems wrong.

I've read that submodule is a bad idea, I'm wondering if people have any experiences/thoughts with something like this?

Upvotes: 1

Views: 46

Answers (1)

Benoit Jadinon
Benoit Jadinon

Reputation: 1161

Git is so better (and easier (and faster)) at branching and merging than SVN, that it is recommended by the git-flow to use branches for working on every new feature then merge when the feature is finished (or discard the branch if it is not working or abandonned)

So, assuming your Code for application A is cross-platform, and can be shared between platforms :

Create a git repo for the Application A project,

Create a second git repo for Code for application A and use it as submodule (or subtree) in every OS project of the main repo, to avoid duplication.

Then whenever working on, let's say, a Windows test, you could create a test branch (like : win-test-refactoring) in the main Application A repo, that would point the Code for application A submodule in the Windows folder to a test branch of his own.

That way, if the test is not working, you can get rid of the test branches, and everything will be back to normal. or if it is working as expected for Windows and needs to be shared with the other platforms, you can merge the test branch with the develop one (in both repos) to include the new feature in the main line, and share it to any folder referencing the libray

Application A (main git repo in its 'testFOO' branch)
|-- Windows
    |-- Code for application A (submodule in its own 'testFOO' branch)
      |-- header
      |-- src
      |-- objdir
  |-- Windows specific code
|-- Mac
  |-- Code for application A (same submodule in its own 'develop' branch)
      |-- header
      |-- src
      |-- objdir
  |-- Mac specific code
|-- Linux
  |-- Code for application A (same submodule in its own 'develop' branch)
    |-- header
    |-- src
    |-- objdir
  |-- Linux specific code

Upvotes: 1

Related Questions