Hi there, we are a small tram of social researchers working on writing a collective report together. The report has several chapters. Our plan is to use git to store changes and easily traceback to different versions as well as allowing everyone to experiment with new ideas.

I am trying to decide a branching strategy, and so far I guess something like feature branching could do. We could have a branch for each chapter…? And maybe, when a chapter is kind ready, we could merge into main…?

We will have members working potentially on different parts of the report in different moments.

Advice is needed. Thank you!

  • EarMaster@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    7 hours ago

    I think this will heavily be influenced by how you distribute your work. Does everyone works on everything (branch by chapters) or is your report clearly divided to every author (then maybe branch by author to make it easier)? In addition every author can decide to branch down further if they feel the need to do so.

  • iii@mander.xyz
    link
    fedilink
    English
    arrow-up
    3
    ·
    15 hours ago

    Sounds like a fine usecase for git.

    I don’t know the structure of your work, and there is not one correct way to do things.

    “Too short” branches would be when you open and merge into main multiple times a day. “Too long” branches would be when one person works on their own branch for months without checking the whole.

    In software, before merging into main, it’s customary to have a person other than the author review and (dis)approve the changes.

    • semperpeppeOP
      link
      fedilink
      arrow-up
      3
      ·
      15 hours ago

      Thank you for your reply! What are the “objects” possibly determining a branch? Features? Chapters? Writers? Releases?

      • iii@mander.xyz
        link
        fedilink
        English
        arrow-up
        2
        ·
        15 hours ago

        The first commit on main would be a rough structure of the document.

        Then branches for each feature (in your case perhaps “abstract”, “chapter 2: intro” “chapter 2: methodology” “chapter 2: conclusion”), and branches for bugs (in your case perhaps: “proofreading and errata chapter 2”, “correct legend figure 4.2”).

  • kubica@fedia.io
    link
    fedilink
    arrow-up
    2
    ·
    15 hours ago

    I have no idea but I suposse it would need some agreement on the index/barebones before anything else.

  • heavydust@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    15 hours ago

    If you have long-lived branches, I would do as you say: treat each branch like its own release, then merge once it’s ready. Make sure that everyone knows that those branches exist and that they must not create new ones. You could create all the branches at once with specific names so that no one is confused (like 01-chapter_something, 02-...)