0

I wonder what is the perfect workflow if one needs to work on project A, B and C in parallel where A depends on B and B depends on C.

Currently I have everything in one repository which speeded up the early development. So my working directory looks like this:

/A/
/A/B
/A/B/C

So A is the project that is driving the development but it also means B and C are in parallel evolvement.

However, I want to release the projects B and C individually as well as they are quite useful for others.

However, I'm torn on how to do this without ruining my development speed. npm is great for distribution and dependency management but during development you definitely don't want to move temporally versions across the internet just to get the files to update in a different folder on your machine :)

On the other hand you also don't want to manually copy them over. Heck, all this I have to switch directories to work on B and now copy it over to /A/B is scary and seems error prone.

So, git submodule seemed like the answer as it's essentially enabling exactly that: You would keep your directory layout just as it is. Then when you make changes to files in B you can directly test them out in A without having to copy something over. And when you think it's ready you can just commit and push from the three different folders. Everything goes into three different repositories automatically. Seems like heaven yet everybody hates git submodule for various reasons.

I have pretty much the same problem when working on grunt plugins. I have the grunt plugin in it's own repository and then when I'm working on it I have to copy it over in one of the projects where I use it to drive the development. And then at the end of the day I copy it back to the grunt plugin working directory, make commits and push them. Thank god, I'm not the author of thousands of grunt plugins so I can deal with that but for this project I'm currently working on, I would definitely like to find a better solution.

So I wonder, what is the answer?

Christoph
  • 26,519
  • 28
  • 95
  • 133

3 Answers3

1

Note that Git submodules point to a specific version of the external repository, i.e. to a specific commit.

To update all Git submodules to the latest version, you’d still have to run a command:

git submodule foreach git pull origin master

Depending on your situation, you could possibly use npm instead of Git submodules. In that case, you simply list your dependencies in package.json, then run npm install in the root of the repository to fetch them. If a dependency is updated and a new version is published, you just run npm update again and it will match the version requirements set in the package.json file. You could also use npm to point to a specific commit, much like how Git submodules work:

{
  "devDependencies": {
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#b3c24169432a924d05020c85f852d4a1736e66d4"
  }
}

Or, if you want to use a bleeding edge version of a dependency, like the master branch of a given Git repository, you could use:

{
  "devDependencies": {
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#master"
  }
}
Community
  • 1
  • 1
Mathias Bynens
  • 144,855
  • 52
  • 216
  • 248
  • interesting. Does that mean I could use `npm` even for pointing to dependencies which are repositories on my local machine? So I could have a `package.json` for local development. Because if I'm on the train, I don't want my workflow to break down because it relies on a working internet connection. – Christoph Nov 21 '13 at 00:00
  • 1
    Yes, you can point to local repositories as well: `{ "devDependencies": { "dependency-a": "*" } }`, then use `npm link /path/to/dependency-a` – Frederic Nov 21 '13 at 05:06
1

I've tried all number of these workflows and have decided that git submodules are not the answer. The main reason for me being that they couple projects together at a scm level and it is not intuitive as to where exactly in the revision history this coupling happens. Especially in a detached head scenario. I rely on npm for depency managment with a combination of npm link and git URLs. npm link is great when I want to test something locally. git URLs are perfect to resolve dependencies during pull requests. Eventually I always want a published module with a version number I can match to a git tag for future reference and issue tracking. I use npm version to do this in one step. Allows for projects to depend on each other at varying levels of coupling during my development cycle.

dam
  • 31
  • 3
0

Would using git subtree be the answer here? This article Alternatives To Git Submodule: Git Subtree did a good job explaining the pros and cons of using git subtree versus git submodules.

Tri Nguyen
  • 9,950
  • 8
  • 40
  • 72