Use of git branches for manuscript journal tailoring and manuscript revision

[tormod]

Hi, I write papers in rmarkdown using rticles and papja. Today I received feedback from one of my submisisons that I had to make some changes (limit references, reduce word count) before the paper could be processed by the journal. In my experience, a paper sometimes had to be sumitted more than once before it finds a good home, and each journal has its own requirements for abstract length, reference styling, headers etc., resulting in several adaptations of the "core" manuscript.

Is this a potential use case for git branches? With my limited experience with git, I think it could be useful to be able to revert to the "core" when submitting the paper to another journal, perhaps allowing more words or tables.

I was also wondering if this could be useful for revising papers after peer review, where I could add edits to the branch tailored to the specific journal which has accepted the paper pending revisions.

Is there any obvious reasons not to do this? Or any best practice recommendations of being able to use this method for processing papers from draft to submission?

For now, I have used sourcetree on my mac for easy switching back and forth from "core"/master and branch, but I can probably do this in Rstudio as well?

Any thoughts? Is this the best idea ever, or among the worst?

[mishabalyasin]

Well, in this case it's mostly about git, not about RStudio, really.

From what you are describing, I would say git is a very nice tool to use since it'll allow you to keep all the changes forever and ever.

However, from my limited experience, I'm not sure branches is the best way to organize this since "core" manuscript is unlikely to be static. This means that you'll find yourself in a situation where branch with journal A need some stuff from branch with journal B. Once you add couple more journals in the mix, it might become a nightmare, I would think.

For example, that's how it looked like for "Tidy Data" paper - https://github.com/hadley/tidy-data/commits/master. As you can see, no branches, just gradual addition. Of course, it's not like there were multiple journals to go in this example, but still.

[csgillespie]

For the last decade I've kept all my papers in a version control system, either svn or git (depends on collaborators). Typically I don't bother using branches for papers, as this means that everyone involved needs to understand what's going on.

But I would recommend using tags

• Isn't intrusive, so doesn't annoy collaborators
• Easy to understand and use

[mishabalyasin]

Big +1 for tags.

I started writing my answer with the punchline being "tags > branches" but lost my train of thought