This is an opportunity to re-evaluate whether keeping FooBar.groovy as a separate library is still desirable. Library code works best when the feature set is pretty stable. Consider moving FooBar.groovy into the current repository if it needs to be updated frequently.

People have the option to add new functions to suit their needs as part of their task. The new functions get submitted with the rest of the test code in their pull request.

If you find that multiple people need a new function, someone can create the function as its own distinct task, and submit a pull request into dev. After completing the PR, anyone can pull the latest from dev to get the new function. Competing changes will result in normal merge conflicts. This is a much simpler approach.

Keeping FooBar.groovy outside the repository means it is a dependency of the project. Now you must manage multiple variations of this dependency, and this is the root cause of your difficulties. Sometimes it just isn't worth making something a shared library.

Even if multiple projects use FooBar.groovy, you must weigh the cost of duplicate effort to add functions versus the overhead required to manage a dependency that is constantly in flux. Copying and pasting this to new projects might be a better choice.

Jon Raynor's answer suggests using git sub modules. While I won't repeat what he said, I will provide a little cautionary info.

Git sub modules allow you to manage dependencies in version control. Some technology stacks do not have a good dependency management solution. Sub modules give you something. Other tech stacks have good dependency management tools. For example, .NET uses NuGet. NPM exists for JavaScript/ECMA Script. PHP has Composer. These tools directly address your problem, however I'm not sure if any such tool exists for Groovy scripts.

Be aware that sub modules (and dependency managers) don't simplify your workflow. A pull request to add a single test could span 2 different repositories (one for the library code and another for the test). This requires two different pull requests. It still means you must merge branches in 2 repositories in order to get that one test in your dev branch.

**Your team might be better served by simplifying your workflow, even at the expense of duplicate effort maintaining reusable test code.**