Use the general git templates for NCI-GDC project. Follow the instruction here to setup for global config or for this particular repo. It contains git hooks to do security scanning for each commit, as well as other type checkings to insure the consistency of coding format.
Feature pattern can simplify development
References
- https://medium.com/opinionated-angularjs/scalable-code-organization-in-angularjs-9f01b594bf06
- https://github.com/mgechev/angularjs-in-patterns
- http://blog.mgechev.com/2014/05/08/angularjs-in-patterns-part-1-overview-of-angularjs/
Page Object pattern can simplify testing
References
- https://github.com/angular/protractor/blob/master/docs/page-objects.md
- http://www.thoughtworks.com/insights/blog/using-page-objects-overcome-protractors-shortcomings
- https://teamgaslight.com/blog/getting-started-with-protractor-and-page-objects-for-angularjs-e2e-testing
- http://spin.atomicobject.com/2014/08/08/page-objects-angular-protractor-specs/
We use the component naming system for css classes based on SUIT CSS.
References
- https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md
- http://atendesigngroup.com/blog/component-element-modifier-design-pattern
- http://smacss.com/book/type-module
- http://bem.info/method/definitions/
- https://github.com/montagejs/montage/wiki/Naming-Conventions
All development should happen on a branch not on master. Branches should formatted as type/GDC-##-couple-words or type/very-short-description.
This branch structure is similar to git flow but customized for our use cases. Also we are not using git flow directly because it has an inflexible release process.
❯ git checkout -b feat/GDC-11-my-feature
References
Commit messages follow a combination of guidelines set by Angular and Tim Pope.
Examples of valid commits:
type(scope): one line description (50 char or less)
type(scope): one line description (50 char or less)
Longer description (70 or less)
- list of changes
- one more thing
type(scope): one line description (50 char or less)
Longer description (70 or less)
- list of changes
- one more thing
Closes ##, ##
Closes ##
This format is automatically checked by a pre commit git hook.
References
- http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
- http://addamhardy.com/blog/2013/06/05/good-commit-messages-and-enforcing-them-with-git-hooks/
- https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
All branches should be pushed to Github for code review.
Any branches containing significant work need to be reviewed and signed-off before they can be considered complete.
References
❯ git rebase -i master
Branches can only be merged after the following is completed:
- Rebased
- Signed Off
- Tested by CI
❯ git tag -s 1.2.3
References
Tags should be signed.
❯ brew install gpg
❯ gpg --gen-key
❯ gpg --list-secret-keys | grep "^sec"
sub XXX/[gpg-key-id] XXX-DATE
❯ git config user.signingkey [gpg-key-id]
❯ gpg -a --export [gpg-key-id] | git hash-object -w --stdin
[object SHA]
❯ git tag -a maintainer-pgp-pub [object SHA]
References
- http://mikegerwitz.com/papers/git-horror-story
- https://fedoraproject.org/wiki/Creating_GPG_Keys
- http://www.javacodegeeks.com/2013/10/signing-git-tags.html
- https://coderwall.com/p/d3uo3w
- http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
No development should happen on the master branch and tests should never be broken.
Version number are based on the current stage of development, in the form:
0.{Phase}.{Month}-spr{Sprint}
For example the version 0.1.8-spr3 represents Phase 1, Monthly deadline 8, Sprint 3
❯ ./release -v 1.1.1 -a prepare
Preparing release for 1.1.1... OK
Checking that there are no uncommited items... OK
Checking that 1.1.1 is greater than 1.1.1-beta... OK
Updating from 1.1.1-beta to 1.1.1... OK
...
Generating changelog from 1.1.1 to HEAD...
Parsed 2 commits.
... make any final changes to docs here if needed ...
❯ ./release -v 1.1.1 -a publish
[master 7d94010] chore(release): Release 1.1.1
2 files changed, 14 insertions(+), 1 deletion(-)
You need a passphrase to unlock the secret key for
user: "{Maintinear Info}"
2048-bit RSA key, ID {Maintainer Key}, created 2014-10-01
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (13/13), 1.92 KiB | 0 bytes/s, done.
Total 13 (delta 6), reused 0 (delta 0)
To [email protected]:nci-gdc/portal-ui.git
* [new tag] 1.1.1 -> 1.1.1
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:nci-gdc/portal-ui.git
5a22164..7d94010 master -> master
❯ ./release.sh -v 1.1.2-beta -a next
Preparing release for 1.1.2-beta... OK
Checking that there are no uncommited items... OK
Checking that 1.1.2-beta is greater than 1.1.1... OK
Updating from 1.1.1 to 1.1.2-beta... OK
[master fd6ced3] chore(release): Start Development on 1.1.2-beta
1 file changed, 1 insertion(+), 1 deletion(-)
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 329 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To [email protected]:nci-gdc/portal-ui.git
7d94010..fd6ced3 master -> master
- clone the repo, git init with template
- create a new branch
- do some work
- commit your changes
- push changes to Github for review
- repeat 2-4 as necessary
- rebase master into your branch and deal with any conflicts.
- get someone to review and sign-off on your branch
- wait for the CI system to test your branch
- have your branch merged into master
- repeat 1-9 until sprint complete
- run release process