Skip to content

Latest commit

 

History

History
80 lines (58 loc) · 2.96 KB

File metadata and controls

80 lines (58 loc) · 2.96 KB

Git and GitHub workflow

⚠️ [github-cli][1] may help you in this workflow, especially to view or test PRs of other contributors. You're encouraged to discover its possibilities.

Main branches

The main RERO ILS git repository has two main branches:

  1. The master branch stays at the latest official release tag.
  2. The staging branch (default branch) contains the work being done during a sprint, between two releases. When the staging branch is ready for a release, the staging branch is pushed into master.
    When a release is ready or needed, depending on the presence or absence of new features, a minor or a patch is published.

Mostly, the PRs will be based on the default branch, that is the staging branch, except when a user story branch is used.

Deployment branches

Basically, there's as many branches as servers. For each branch, there's an image on Docker Hub:

Each deployment branch is built as needed, especially the ils_dev branch that may contain all the commits that need to be tested. On these branches, force pushing is not an issue, as they aren't used for development

Critical bug fix

When a critical bug needs to be fixed as quick as possible, a branch is created from the last tag in production (usually the master branch), named <last-tag>-fix-yyyymmdd. This branch will contain the fix. Depending on the situation, then this commit will need to be added to the staging branch too.

Publishing a release

When a less critical bug is fixed by a commit on the staging branch, a release is published, which could be a minor or a patch version.

When reaching the end of the current sprint, a release may be published. Depending on breaking changes, it may be a major or a minor version.

From a contributor point of view

Each contributor has his or her own fork and opens a PR (pull request) using either the staging branch as its base, or a specific branch corresponding to a user story (US), such as US-<name>.

Updating your branches

  1. Fetch the changes:
    • git fetch --all -p (fetch changes of all remotes and prune).
  2. Place yourself in the branch you want to update:
    • git checkout [branch name] or
    • git switch [branch name].
  3. Update your branch:
    • git pull [remote name] [branch name] or
    • git rebase [remote name]/[branch name] or
    • git reset --hard [remote name]/[branch name] (this will overwrite all your local changes).

Very often, you'll need to rebase your working branch on the staging branch, because the staging branch has moved just before your PR opening or merging:

  • git switch <your-working-branch-name>
  • git rebase <main-rero-ils-remote-name>/dev

You may need to resolve conflicts.