Skip to content

Minor thoughts on version control #6

@cbedwards-dfw

Description

@cbedwards-dfw

https://phac-modelling-hub.github.io/dev-practices/projects/version-control.html

More fantastic material. Minor thoughts:

  • My go-to reference for getting set up with git when using R/Rstudio is Happy Git with R: https://happygitwithr.com/. I'm not sure where it would be appropriate to link it, but it's a fantastic resource.
  • Just my own personal experiences in a very different organization, but sometimes it's helpful to have the repositories not nested within the user. For example, depending on cloud backup handling, material in the user folder may all have some amount of cloud backup, interfering with git behavior. For my team, the common practice is to put the files in C:/Repos/, which is a folder our IT expects users to be able to edit. Might be best to leave the document as is, just wanted to bring this to your attention.
  • In the "Working with Branches" section when talking about naming branches, suggest avoiding spaces in branch names.
  • Re: Footnote 1: the bigger problem for long-standing projects is that git can't use its diff-based approach to efficiently store changes, so each commit with a change to a word or excel file saves the new version as a completely new file in the git history. Over time the repository can become bloated with a git history that's full of every iteration of a word doc (or powerpoint, or whatever) and can easily reach the size limit for Github (and presumably GitLabs). I've had to wipe clean repository histories because of this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions