Document code review process at OKI #6
Conversation
|
|
||
| Submitting code for review should follow these steps: | ||
|
|
||
| 1. Work out of your own fork of the main repository (usually `origin`). |
There was a problem hiding this comment.
Is that really necessary? You can submit PRs from the feature branch to the master branch even if the are in the same repo.
There was a problem hiding this comment.
I usually do exactly as you describe. I'm easy.
There was a problem hiding this comment.
I think either is okay, as long as old feature branches are removed from the origin repo when no longer needed.
There was a problem hiding this comment.
@brew yes that is the main annoying thing. In the last year I removed something like 20 branches from both OpenSpending and Open Data Census because people just merged PRs and left their mess around :)
There was a problem hiding this comment.
Perhaps we should add this to the coding-standards: It's the merger's responsibility to remove redundant feature branches.
btw - git cli can be useful for periodic branch pruning with git branch --merged and git branch --no-merged.
There was a problem hiding this comment.
@brew thanks for the branch pruning tip!
|
|
||
| ## How | ||
|
|
||
| The process for code reviews is straight forward as long as you are already following our coding standards for working with version control, and in particular our git flow-influenced process of branch management. The bottom line is that, before any code hits `master`, it must be reviewed by a colleague. |
There was a problem hiding this comment.
must is very strong. I still have concerns that this stricture doesn't fit in with all projects. Especially in the early stages of a new project.
Document code review process at OKI
No description provided.