Carolina Digital Repository 2.0 In contrast, the CDR 2.0 will be dedicated to academic contents. The platform is based on the open source Hyrax repository front-end and this is also where the majority of my user research works go into: everything from usability testing to web accessibility evaluation.
Document your code
Every project on GitHub comes with a version-controlled wiki to give your documentation the high level of care it deserves. It’s easy to create well-maintained, Markdown or rich text documentation alongside your code.
Sign up for free See pricing for teams and enterprises
This page will show you how to create and use a maintenance branch from any commit or from a release tag.
Creating the branch
- check for existing maintenance branch so as not to duplicate
git pull
- first update local repository from remotegit branch -l
- list branches
- find the starting point (commit or tag). Look at the history or tag list to find the starting point you want:
git hist
- find commit idsgit tag -l
- find release tags
- create a new tracked remote branch
git checkout --track -b <major version>.x <tag/commit>
, for examplegit checkout --track -b 2.x 2.0
- update POMs to next minor SNAPSHOT version
mvn versions:set -DnewVersion=<version+1>-SNAPSHOT -DgenerateBackupPoms=false
(inserts new version into POMs. increment the proper version digit)vim pom.xml
- update the cdr-version property in parent POM (updates dependencies)- We will create tags for minor releases, but will use the one maintenance branch per major version.
- fix bugs
- Fix bugs on the branch and commit changes to your local repository.
- Optionally consolidate/squash commits together with
git commit --amend
orgit rebase -i
- Push changes to remote repository
Performing a maintenance release
- follow the normal release procedure to deploy a maintenance branch.
How to merge minor fixes into a major branch
-
Commit your fixes on the proper release maintenance branch. (How to release the cdr)
-
Before any major release and at any time prior to that, perform a biased merge from maintenance to master (or major release branch).
git checkout <branch>
, where branch is the major branch or mastergit merge -s recursive -X ours <fixes-branch>
(In a conflict this will keep the master change.)- commit the merge, if not done automatically.
- push the major/master branch back to origin