Skip to content

Home

Jump to bottom
Eliot Kimber edited this page Sep 11, 2021 · 3 revisions

DITA Specializations

This repository contains DITA specializations that were originally created by the DITA TC as part of the DITA specification but were removed (i.e., in the transition from DITA 1.x to DITA 2.x).

Branching policy

The branch "main" represents "released" code, that is, things that have been fully tested, verified, and deemed ready for general use.

The branch "develop" represents active development. All new and changed code must be merged to develop (from feature branches) and reviewed by the relevant stakeholders before being released to the main branch.

Contributing

All changes should be developed on and pushed to this repository via a feature request that is then assigned for review and approval as appropriate.

All changes should be developed in the context of an issue logged in this project's issue list. Use the issue number in the feature branch name and in commit messages (i.e. "#2: Corrected public IDs for learning and training modules").

The general process is:

  1. In your local clone, do:

    git fetch --prune
git checkout develop
git pull

  2. Create a new feature branch to do your work on:

    git checkout -b feature/issue-99-correct-typo-in-something

  3. Do your work, committing to your feature branch as needed.

  4. When you think your work is ready to merge or you need other contributors to look at, push your branch to GitHub:

    git push -u origin feature/issue-99-correct-typo-in-something

  5. Go to the dita-specializations project on GitHub. You should see a message that your branch was just pushed and asking you to create a pull request ("Compare and pull request"). Click the "Compare and pull request button" to create the new pull request.

  6. In the pull request form, add any relevant details for reviewers (if any) and add reviewers if your change requires a review. Set any other properties as appropriate.

  7. Create the pull request.

  8. If the request requires review, nag your reviewers until they do the review you need. You can continue to make changes on the feature branch and push them to GitHub--the pull request will reflect those changes. The pull request can serve as a channel for working through review comments.

  9. If the merge request is approved or otherwise ready to be merged, click on the "Squash and merge" button (the repository only allows squash and rebase merges and you should almost always use squash merges). Update the commit message as appropriate and do the merge.

  10. If the merge is not approved or your change is otherwise not something that should be merged, simply delete the merge request.

  11. In either case (merge or abandon), delete the feature branch from GitHub

  12. In your local clone, do the following:

    git fetch --prune
git checkout develop
git pull
git branch -D feature/issue-99-correct-typo-in-something

    The fetch --prune records the fact that the feature branch was deleted from the remote repository and gets the latest data for the develop branch. The -D (uppercase D) flag forces deletion of the branch, which git otherwise refuses to do because it sees the branch as "not fully merged" due to the squash merge into develop. But you know it's safe to delete the branch because you just merged it and you saw the changes from it coming down on the develop branch.

You're now ready to make a new feature branch for your next contribution.

Clone this wiki locally