And it also lets us know that this revision is a tag, named “6.16.3”. This returns the currently checked out revision of our lib/spacetime submodule. If you want to find out what revision your submodules are using, you can request this information in your main project: $ git submodule statusĮa703a7d557efd90ccae894db96368d750be93b6 lib/spacetime ( 6.16.3 ) Simply because you don’t know if those new changes might break your project! When the library’s maintainer releases a new version, that’s all well and good … but you don’t necessarily want this new version to be automatically used in your project. Think about it: when you include a third-party library, you want to have complete control over what exact code is being used in your main project. This behavior, of course, is not a mistake. In a submodule, we’re always checking out a specific revision - not a branch! Even when you’re executing a command like git checkout main in a submodule, in the background, the currently latest commit on that branch is noted - not the branch itself. This is important to understand - because Git submodules work differently! When new commits are made on this branch, the HEAD pointer is automatically moved to the very latest commit. By using git checkout or the newer git switch, we’re telling Git what our currently active branch should be. In a “normal” Git repository, we usually check out branches. The even better way is to simply add the -recurse-submodules option right when you call git clone in the first place. In such a case, to populate submodules after you’ve cloned their parent repository, you can simply execute git submodule update -init -recursive afterwards. If we performed a vanilla git clone on the command line, we would download the main project - but we would find any submodule folder empty! This again is vivid proof that submodule files are separate and not included in their parent repositories. But what about “the other way around”, when you clone a repository that already contains submodules? In our example above, we added a new submodule to an existing Git repository. ![]() Maybe you just want to share your own code between two projects - a situation where submodules might offer the simplest possible workflow. Not every piece of code might be available over a package manager.Submodules, on the other hand, always work the same. Especially if you’re working with multiple technologies, each one might have its own package manager with its own set of rules and commands. Submodules provide a consistent, reliable interface - no matter what language or framework you’re using.However, you could argue that Git’s submodule architecture comes with a couple of advantages: You could also use one of the various “package manager” systems that many modern languages and frameworks provide. ![]() Luckily, Git’s submodule concept was made for exactly these situations.īut of course, submodules aren’t the only available solution for this kind of problem. ![]() And it’s certainly true for managing third-party code in your own projects. The general rule in software development to “keep separate things separate” exists for a reason.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |