I would definitely recommend submodules instead of plain include if you plan to have different people working on them. Modules in julia serve to separate namespaces, and you don’t want name-clashes between helper functions or constants like _compute_stuff in evaporation and transpiration. Furthermore, this simplifies debugging.
Regarding exports and using, this is pure syntactic sugar once fully qualified names start hurting readability (Evaporation.evaporate(...) is much more readable if you have few call-sites, because the reader doesn’t need to look up what module this comes from, but the verbosity hurts readability if call-sites are all over the place; I suggest always starting with plain import, and refactoring to using once you have many call-sites).
Regarding packaging and physical organization, think about whether it will be common that a single git commit needs to touch several of your modules. It sounds like that will be the case; hence I would recommend sticking to a single git repo and a single package for the beginning. Regarding physical organization into several source files, the same applies: Too many tiny files hurt readability, too few huge files cause perpetual merge conflicts in git.