I'll describe how this is typically handled in github. However all of that is just code, so it is relevant elsewhere.
Really spiffy projects like the ones I run, have tests to make sure everything is working okay.
Furthermore, the way cool projects like the ones I work with have some sort of continuous integration. That just means there is a way for some external independent system to run the tests on its own. github arranges a project to used a canned set of git commit hooks which will tell the independent system that a change has been commited.
Usually there are instructions that you can provide to the continuous integration system that help it build the system. Specifically these instructions or configuration might specify what version(s) of OCaml to test with.
With all of this in place, when you submit a "pull request", github runs the git hook which kicks off the continous integration system which then makes available the status of the check. Github will then notice it (because the hook was canned and custom for a ci so it knows where to look). And then it will alert the potential owner whether it is safe to merge the code or not. Even without continuous integration github will do a merge off to the side just to make sure there are no merge conflicts.
Ok. But let's suppose you are working with less sophisticated projects. Since this is git, that's cool too, it can help you on its own.
Here what you could do then is make a branch and restrict your changes to that branch. Then request a pull from that branch. The owner will probably merge your changes into a similarly-named branch and then try it out. If things work okay, then that person will merge the branch into the "main" branch.
And in fact whether you are using github and the fancy stuff or not, it is always good to work in a branch for your changes off of another project. See also git flow