Git structure

branches

• feature branch
  • checked out from 'development' - after a pull from team repo
  • where all the development is made
  • merged back to development after commits and test runs
• development
  • from where the feature branches are created
  • all the commits wil be running from here
  • where the merge conflicts will occur and resolve
  • serves as a proxy to release
• release
  • reflects what will come out on the next release
  • exists so we can cherry pick from development
• master
  • will always reflect what is in production

Dev Cycle

• Setup
• Development
• Code Reviews
• Acceptance / Merge

Setup

• each project has a repo, every dev subscribes to its notifications
   
• each dev forks the main repository on github
   
• clones his fork and checks out the development branch
   
• the master and release branches should remain untouched

• post_checkout hook will call 'grunt setup' which
  • ads the remotes for the team repo each team member's repo 
  • ... other things that we find useful
     
• we can use something like yeoman to bootstrap every new repo

Development

• developer pulls from 'development' gets the latest code (commits and tags)
• creates a feature branch from 'development'
• CODING!!!!!!
• git diff and git add for each modified/added file
  • git diff provides self code-review
  • never use 'git add .' - i think this is a no-brainer
  • each commit should be atomic, refer to one set of related code changes that translate to a particular development
• pre-commit hook will run the Unit Tests - 'grunt test' - and only proceed if tests pass
• checks out development branch
• pulls from 'teamrepo/development'
• merges the feature branch onto development
• resolve merge conflicts if any
• push to fork-developer/development
• fire a pull request in github
  • name the pull request with the required meta-data
    • type (issue, new development, ...)
    • threat level (1-5) - urgency to go live
    • title - short summary of the changes
    • description - more detailed description of the changes (not visible on the list)
  • comment with any information that seems relevant

Code Review

• Every Senior Dev is a Reviewer
• Rev should be always aware of the flux of pull requests, through the email notifications received by email from github
• According to that flux, he/she should make time between 'flows' and pick up a PR or two
• Rev should use own common sense too prioritize using the meta left by the developer
  • that meta should be easily distinguished in the list of PRs waiting for acceptance
• when picking up a PR for review, rev leaves a comment ('in review by') informing others so they don't pick up the same PR
• CODE REVEW!!!
• if changes need to be made, leave comments (for the commit or for individual lines) so the dev is notified and corrects the changes
  • if this is the case, the process starts all over again when the dev commits corrections
• if review is favorable, ACCEPT the PR and merge it with the development branch of the main repo

SHORTCUTS

Because life isn't perfect and we know what we're doing, sometimes it is allowed to take certain shortcuts that will facilitate a better swiftness to the process; we may want to use these shortcuts mostly for two mutually exclusive reasons: high urgency of getting the code live (ie live issue) or low risk (ie small change that has very little chance to break anything); these should not be abused, though. Here are some examples:

• Self Code Reviews and PR acceptance
• Asking someone to review the code immediately (take a good look not to interrupt someone in 'the flow')

Code Reviews

what to look for

• Code Smells
• things that would not break the tests but shouldn't be there
  • forgotten console.logs
  • ......................
• better approaches to parts of the logic that could lead to better performance, better readability or accordance to standards
  • you should discuss them with the dev only after you are confident there's a reason to change
  • developer shouldn't feel threatened or offended - we all love to learn