All of the below guidelines are just suggestions. They are not meant to create additional "red tape" during the normal development process. If you find they are getting in the way, let us know, we can always change them! Development processes and best practices change over time, and these guidelines should be no different. |
By "Main Branch" we are not only referring to DSpace/DSpace in GitHub. We're also referring to the Main branch of any other production-quality, out-of-the-box GitHub projects (e.g. DSpace/dspace-api-lang, etc.) |
The GitHub Main branch is one of the few places that needs to remain well managed. As we all fork it and/or create Pull Requests from it, it can be detrimental to us all if incomplete or extremely buggy code is committed. Obviously, mistakes happen (and we've all made them), so don't worry if you accidentally commit/merge something you didn't mean to (just try to roll it back as soon as you notice it). Here are the few rules we try to follow when committing code to the Main branch:
To collaborate in the private fork, you will need to either: clone that private repository, or add it as a new remote. The latter tends to be easier, and may be done as follows:
# Add the private repo as a new remote git remote add DSpace-ghsa-[id] git@github.com:DSpace/DSpace-ghsa-[id].git # Pull down that repo git remote update # Checkout the branch you are collaborating on git checkout -b [local-branch-name] DSpace-ghsa-[id]/[remote-branch] |
main
which will make them public. So you may want to wait until the release is almost ready to do this.