-
Notifications
You must be signed in to change notification settings - Fork 0
git
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.
Nothing is to go into the repo except text. All images should be svg, as it's parsed as text.
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.idxandmakeglossaries mainhave completed. - Search the pdf for the string
??, which shows a missing page reference.
The config directory's a subtree, so:
- No git commit should reference the
configdirectory and others. - Attention should be taken to ensure changes there won't adversely affect other projects.
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.
Mostly git merges work fine. The main pain point is having an unnoticed \begin{stuff} without the \end{stuff}, or vice versa.