evergreen-docs:github-workflow
This is an old revision of the document!
Docs GitHub Workflow
When someone submits a change via GitHub, an Evergreen developer should follow these steps to review it:
- If you haven't yet, add the main Evergreen repo (on GitHub) as a remote
git remote add github-evergreen https://github.com/evergreen-library-system/Evergreen.git
- Update your local master branch to reflect any changes from "origin"
git checkout master; git fetch origin; git pull origin master
- Fetch the pull request branch into a new local branch
git fetch github-evergreen pull/[PULL_REQ_NUMBER]/head:[BRANCHNAME]
- Checkout your new pull request branch
git checkout [BRANCHNAME]
- Rebase the pull request branch to master, and handle any conflicts
git rebase master
- Test build the changed AsciiDoc file
asciidoc -a data-uri -a icons -a toc -d book -o OUTPUT_FILE ASCIIDOC_FILE
- Ignore warnings for not finding any image files, but be sure to review any included images on GitHub before committing them
- Also look for other AsciiDoc warnings or errors
- Make any corrections (via additional commits, if needed)
- Use interactive rebase to add the commits to your local master, adding your sign-off
git checkout master
git rebase -i [BRANCH_NAME]^
(note the caret!)- Include the relevant Launchpad bug number somewhere in the commit message
- Example: "Resolves LP#1234567"
- Out-dent the sign-off line (if present)
- Add newlines to long commit messages, making lines about 72 characters long
- (If the GitHub author does not match the author's identity in git.evergreen-ils.org, consider fixing it with
git commit --amend --author="NAME <email>"
)
- When you are confident your commits are ready:
git push origin master
- Backport to previous EG versions as appropriate
- Email docs list and/or pull requester to say it is done (or with other feedback)
- Close pull request on GitHub
evergreen-docs/github-workflow.1418413756.txt.gz · Last modified: 2022/02/10 13:34 (external edit)