Each sprint will have the following branches in the GitHub repository

  1. Sprint branch
    1. Branched from head (main) at start of sprint
    2. May be behind head at end of sprint if patches or high priority features are merged into head.
    3. Ideally starting point of each sprint feature branch. Not always possible for some features will depend on one or more features of the sprint. In that case it is best to create a merge branch of dependent features to afford optimal isolation of features.
    4. This branch represents where a sprint has been started and affords ability to cleanly rebuild another staging branch in the case it is required. For instance, it might be required by failed integration of features or unaccepted features by VIVO leadership group. 
    5. This branch after its creation from the main repository branch might have a PR from a feature lead. A feature lead is the owner of the main idea for a feature which should be developed during the sprint, or a person with the highest expertise for that feature in the sprint team. The PR should define main frame for the feature implementation or represent implementation of proof-of-concept with the goal to make the sprint feature implementation smoothly.  The PR will be reviewed and merged by VIVO core team members.
  2. Sprint staging branch
    1. All feature branches submit PR to, i.e., this branch should ensure feature integration during the sprint. It should also be used for infrastructure deployment for demonstration purposes (to VIVO leadership group or interested VIVO stakeholders/customers).
    2. The staging branch upon approval of features should then submit PR to head in which should undergo another high-level review by committer team.  This high-level team review is to ensure no merge issues, consistency in design and style, and test coverage of feature integration. 
  3. Feature branches
    1. Should be as isolated as possible for review. When feature depends on other work from the sprint feature merge branches should be used to have optimal isolation.
    2. All feature branches should submit PR to sprint staging.
    3. Each feature PR should be linked to an issue.

It is also recommended to adopt a branch naming convention.

i.e.

dynaic-api-sprint1
dynaic-api-sprint1-staging


<issue number>-<feature title>
e.g.
114-dynamic-api-controller


Should also consider commit message conventions and more importantly PR merge strategy. For the project commit history to have increased value it should be considered to use squash and merge for feature PRs. This will allow for clean feature commits in the history but can be difficult to achieve with many interdependent features.

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.