From 92b9d5ae6471ccebbabb9836f9b6494ff3ef0227 Mon Sep 17 00:00:00 2001 From: Tom van Woudenberg Date: Thu, 27 Jun 2024 09:05:56 +0200 Subject: [PATCH] Update organize-team.md --- book/installation-and-setup/organize-team.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/installation-and-setup/organize-team.md b/book/installation-and-setup/organize-team.md index 9488117..4da66bc 100644 --- a/book/installation-and-setup/organize-team.md +++ b/book/installation-and-setup/organize-team.md @@ -23,10 +23,10 @@ If you want to create a collaborative book for students, there's a few agreement - Choose whether to have your git repository public or private (independent of whether your book website is public or private). If you'd like a private repo on GitHub, apply for a GitHub Team (free as a teacher as described in the [github documentation](https://docs.github.com/en/education/explore-the-benefits-of-teaching-and-learning-with-github-education/github-education-for-teachers/about-github-education-for-teachers#github-education-features-for-teachers)). If you've a organization for your book on github, link your GitHub team rights to your organization as described on the [github website](https://github.com/team#organizations) - If you've chosen for GitHub, start with our [template](../external/template/README.md) - Define branches in GitHub/GitLab. We advise the following branches: - - A published branch which contains the students' version of this year. This could be called ie. `publish` or `main` or ``. Add this branch as the `PRIMARY BRANCH` when making use of the [github workflow](gh-workflow-settings), this will make sure students are redirected to this URL which doesn't move when adding new versions of the book later on. If you plan on keeping only one version, it's adviser to set `BEHAVIOR_PRIMARY` to `copy` to copy the primary branch to root so that the URL is compact. - - A development branch which contains all the new content combined but not yet published to students. This could be called `dev` or `main` (depending on whether you prefer having the most recent published version as main or the development branch). - - Branches which will be created during the editing process which contain edits ie. single chapters - - Branches for previous study years which contain each year's version of the book. These could be called ``. Add these branches to the list of `BRANCHES_ARCHIVED` when making use of the [github workflow](gh-workflow-settings). + - A published branch which contains the students' version of this year. This could be called ie. `publish` or `main` or ``. Add this branch as the `PRIMARY BRANCH` when making use of the [github workflow](gh-workflow-settings), this will make sure students are redirected to this URL which doesn't move when adding new versions of the book later on. If you plan on keeping only one public version, it's advised to set `BEHAVIOR_PRIMARY` from the default `redirect` to `copy` which makes sure the primary branch is copied to root so that the URL is compact. + - A development branch which contains all the new content combined but not yet published to students. This could be called ie. `dev` or `main`. `dev` is advised when you prefer git's default branch to be the most recent published version (as `main` is expected to be the default branch by many). + - Branches which will be created during the editing process, which is probably something which you want to allow. As long as `BRANCHES_TO_DEPLOY` is set to the default `*`, all branches are build and your fellow editors can review their own and each other's versions online. Once every while, it doesn't hurt to go through the list of branches and delete any branches which are merged but not deleted. + - (future) branches for previous study years which contain each year's version of the book. These could be called `` which ends up in their url too. Add these branches to the list of `BRANCHES_ARCHIVED` when making use of the [github workflow](gh-workflow-settings) to add a banner to the page indicating it's archived state. - Setup protected branches in GitHub/GitLab to prevent accidental changes - Add people with GitHub/GitLab permission matching their role and the protected branches. - Add a readme explaining the way you organized branches and permissions