At the beginning of your Rmd file, add a chunk that spins your Rmd file to an R script.

https://www.garrickadenbuie.com/blog/convert-r-markdown-rmd-...

Now you have:

- single file (Rmd, plain text) where you can do any edits, which, when compiled, produces:

- (1) you get story, code and results in a single package: one output file (usually, html), where all inputs and outputs are stored together (or, just the outputs, if you turn off echo'ing, e.g. for producing a report),

- (2) you get the code: another output file, which is a simple R script version of your Rmd file.

Code updates to the Rmd are viewable much easier on the output R script (#2), which is also much more convenient for debugging. For static text updates, I look at the Rmd file. For content updates (e.g. did my data change between the runs?), I look at the html (or Word or PDF etc) file (#1).

With Rmarkdown you have 2 options, both have its own merits

1. save code and output separately, so you can save the output (but not comparing the output versions), or always generate output from scratch when needed (this actually help to ensure reproducibility)

2. or you can use R notebook format, which save the result with document together, in some companion folders.

Output stored with input is precisely the problem for version control. Not only committing generated content but generated content mixed with source code.

the .rmd is just text. But the output is cached separately, RStudio can load the full notebook, code and output. So it seems to me it's only a matter of how to integrate the .rmd with the output data so it can be displayed in interfaces other than RStudio.

Plus you get the option of rendering an HTML which IMO is no different than having a jupyter file.