Not a serious issue, just to know how others are doing it. My team has been adding the js output to the version control. There are pros and cons. Pros: checking the diff of js output, keep integration between ReScript expression and runtime representation, Cons: too many diff and conflict, not always see the diff.
Curious about how you’re doing it.
Versioning .bs.js might be a good infiltration strategy to adopt ReScript in your workplace.
That said I think the benefit is marginal when the codebase is already written in pure ReScript.
The most painful thing is, as @moondaddi mentioned, resolving conflicts between branches.
Another aspect is that I barely care about the output.
ReScript’s pickup line from the title page mentions the ‘readability’ of compiled output.
But in my experience, almost every beginner introduced to this phrase, is curious ‘why should I care about JS again?’
I accept this as a fair complaint since that is the purpose of choosing high-level languages.
Hence tracking all the outputs in git might be a good trick in some situations, but better not recommended in general.
I have .bs.js under version control for all my libraries, because it gives you more control over the generated code. You can see actual changes, how they affect performance, bundle-size and etc.
But I don’t see many benefits to do so for applications.
Oh my lovely js output. 
Sometimes it makes sense to compare the differences, for instance when you test a new compiler version. But then it is simpler to compile it with the old version, update, compile with the new version, and just have a look at the changes. You really do not need to deal with the diffs all the time IMO.
For libraries or brownfield projects that introduce ReScript, it is probably more useful, but for our use-cases, I really prefer to not need to read the same code twice and have smaller diffs.
Even for the libraries, I’d rather say the performance issue is compilers concern.
“Predictably fast” is one of the goals from very early days 
I started with them in version control, and then it was so annoying and useless that I removed them all. I don’t see any benefit unless in the very specific cases already mentioned.
To be honest, I never look back, and nobody in our team did either.
Agree, the compiler generates very optimised code. In my case I had a goal to write the fastest parsing library so I cared about performance more than usual. Mostly bs.js helped to detect some unwanted Curry._1 and to detect some function calls that can be inlined. Also, it helped to see how features affect bundle-size, and measure it using external tools like: bundlejs.