Skip to content
Malin Freeborn edited this page Sep 10, 2022 · 10 revisions

Standard Workflow

I think my git workflow's pretty standard, but just to be explicit:

I normally work on the dev branch. Commits here should compile fine.

If unsure about a change, or working on a rules change (which requires many edits across files) a new branch is created. If the change affects another project (such as Adventures in Fenestra), then that project should have a branch of the same name.

Text Only

Nothing is to go into the repo except text. All images should be svg, as it's parsed as text.

Master Merges

Clean the dev branch and make sure there are no formatting errors, such as wonky tables, or ugly whitespace caused by those tcolorboxes jumping about, then merge to master. Once the push goes through the book's automatically compiled in the gitlab pipe.

A few things to check are:

  • Display the book two-pages at a time, and flip through every page to check quickly.
  • Make sure makeindex main.idx and makeglossaries main have completed.
  • Search the pdf for the string ??, which shows a missing page reference.

The Config Subtree

The config directory's a subtree, so:

  1. No git commit should reference the config directory and others.
  2. Attention should be taken to ensure changes there won't adversely affect other projects.

How to Take Courage

Don't worry about screw up pushes. Just make a new development branch, and push that out. If it all goes wrong, we can fix it in post. Just don't push to the master unless you know what you're doing.

For a video overview of the workflow, go here.

Hunting Wabits and Multicols

Mostly git merges work fine. The main pain point is having an unnoticed \begin{stuff} without the \end{stuff}, or vice versa.

Clone this wiki locally