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.
#Git submodule detached head update
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.
#Git submodule detached head code
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.
0 kommentar(er)
