Make sense? Basically, you commit to the Git submodule separately just like you used to commit to your SVN external. When you’ve committed your changes to the submodule and have it in the state you want for its inclusion in the parent project, you then need to cd back up to the parent project and commit the “change” of the state of the submodule. Like SVN externals, you need to cd into the submodule to commit any changes you’ve made. Git submodules work in a somewhat similar fashion in that you need to commit the changes to the submodule first but there are also some additional steps involved. When I did this, I’d need to commit to the external separately from the parent project. When I was doing active development on a project that had SVN externals, I’d often end up making changes to the externals as well as the current project. Recovering from this isn’t particularly hard (I’ll do a follow up post with details on this), it’s just another step in learning how Git wants you to work with submodules.
If you’re not used to this (or are used to how SVN externals work), it’s easy to accidentally start editing code in the submodule code while you’re on a detached head.
This means that even though the submodule is pointing to the correct ref/code revision, but it isn’t setup to update from or commit to a specific head (branch). (thanks Shawn) Submodules require extra steps when committingĪfter initialization, your submodule will initially be in a “detached head” state. This step will get all if your submodules setup, pointing to the proper refs, etc. From inside the newly cloned repo (at the top level), you have to initialize and update the submodules: With Git submodules, an additional step is required after a git clone. With a standard SVN checkout, all of your externals get populated and are ready to go right away. Submodules require extra steps when cloning while the other includes design docs, mockups, etc. One has just the code, README, CHANGELOG, etc. This means you’ll want to keep your code repositories lean and mean – you don’t want deep URL paths or a bunch of historical design documents and other things in there that would be considered cruft when the repo is used as a library for another project.īecause of this, we’re often maintaining two Git repos for each project. With SVN you can make your external point to a subdirectory of a project (this is how you’d choose trunk vs tags/1.0.2, etc.), with Git the submodule will always be the entire project. The submodule will be the entire Git repo
With Git’s submodules, you can still bring in another codebase into your project but the mechanics of it are a bit different.
You might be pulling in changes on each “svn up” that you don’t want. Primarily you can run into multiple people updating or needing to work on an external at the same time (and SVN doesn’t well support a branch-driven development model). That doesn’t mean there aren’t some challenges there. Like I said, it’s something you can get away with. If you follow a good trunk/branches/tags model within your externals, you can get away with this without too much trouble you primarily point the external to the latest stable tag, but switch the pointer to trunk when active development is needed. With SVN externals, the included externals are automatically updated to the latest version on every update (unless you –exclude-submodules). Often times active development would be happening on a specific project and within one or more of the externals within the project (to support a new feature, etc.). To support this approach we previously made extensive use of SVN externals in our projects. it’s easier to test smaller sets of features/functions.smaller bits of code are easier to maintain, update, debug, etc.I thought the following notes might be useful to other folks making the leap as well.Īt Crowd Favorite we write modular code (for example: lots of lean, targeted WordPress plugins instead of few complex plugins) for a number of reasons: Since our migration from SVN to Git, I’ve seen other folks on our team working through the same hiccups I had initially. One of the biggest hurdles I had to get past in order to use Git efficiently was getting my head around the differences between SVN’s externals and Git’s submodules.