The short answer is no, you can't do that (any of those three things, really). The longer answer is still no, but explains why.
The first problem you have here is that files, in Git, don't have dates. That's perhaps not such a big problem because Git doesn't store files in the first place: Git stores commits. Commits do have dates, and then commits have files as well, so you could just use the commit date as the pseudo-date of each of the files within the commit. You could then pick the newest commit's version of the file. Merging works by commits so the fact that it's the commit that has the date should (logically) not be a problem here (though note that physically accessing the commit date would be a big problem, once you get down to this level).
But this still isn't really want you want—and in any case, there's no mechanism for this built into Git. Git isn't interested in dates during merging. Git is interested only in file content. You could attempt to use ElpieKay's suggestion of applying a merge driver (this link goes to the gitattributes documentation, which is where you will see a description of merge drivers), but it turns out this is not a good approach either. See .gitattributes merge strategy not working for an explanation about why it's not so good. (The TL;DR part is that your custom merge driver is not used unless there is some merging to be done, and sometimes there isn't any merging to be done. In one case this works in your favor, and the other case, it fails.)
In fact, the best approach is almost certainly to not store the build version number in Git at all. If you have a work-tree file named version.txt that is not in any commit at all, this will simply be an untracked file that you can keep out of all commits. Changing from one commit to another will not touch this file, as it is never part of the repository. Checking out a branch changes which commit you're using, but since the file isn't in the commit, it won't be copied out to your work-tree. It's too late to do this with a file that you've already included in existing commits, since those commits literally cannot be changed, but you can either rewrite your repository history, or just change the name of the file.
To keep the untracked file untracked, it will help to list its name in a .gitignore file. Note that listing a file in .gitignore has no effect if that file is already tracked, i.e., is in Git's index. (The answer to the question of when a file is in Git's index is rather long.)
