Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-2456

Investigate: Different default branch on cloning

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Sometimes it is hard to explain our workflow to new developers because the term "master branch" is a bit weird. The term implies that we also have a lot of servant branches that do what the master branch is telling them.

      This is not what is actually going on, which makes the whole thing hard to communicate.

      In the fork-and-branch workflow we normally use, we use the "master" branch as a kind of main branch, or development branch. As we are working on a project, we submit pull requests from topic branches hosted on our personal forks to the "master" branch on the the main, team repository.

      Also, sometimes sub-teams of developers make a fork of the team repository and then merge branches from team members into that fork. Then they submit a PR to the team repository.

      Even the term "team repository" is confusing because it's not specific enough. We have lots of "teams" and so any repository being shared by > 1 person is a "team" repository.

      So maybe we can change the terms to something like "main":

      • main branch - the branch everybody's commits get merged into; the branch that everybody's topic branches emerge from
      • main repository - the authoritative repository for the project; the thing hosting all the release branches that get built and distributed on bioviz.org

      instead of:

      • master branch
      • team repository

      The Bitbucket hosting service lets us choose which branch we want to function as the default branch shown when people visit the repository on-line.

      Before we make any major changes to our workflow, we ought to investigate the feasibility!

      We could try this out on a few of our less active repositories but history-rich repositories, e.g., the "bioviz" repository, to determine how making this type of change will affect project history.

      In addition, we should investigate how this will affect repositories using bitbucket pipelines. Will the pipeline still run properly? How will we need to modify our pipeline configuration file?

      For this task, we need somebody to think about all the various issues and develop a kind of playbook for how to make this change.

      Suggestions;

        Attachments

          Activity

          Hide
          ann.loraine Ann Loraine added a comment -

          The guide above is clear. It should be very possible to do this. Moving to Closed.

          Show
          ann.loraine Ann Loraine added a comment - The guide above is clear. It should be very possible to do this. Moving to Closed.

            People

            • Assignee:
              ann.loraine Ann Loraine
              Reporter:
              ann.loraine Ann Loraine
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: