CodeReview.md - wiki - Git at Google

 # Requirements

 All commits and must be reviewed by at least one Melange engineer other than the author before migration to the master branch.

 # Author Process

 When you feel that your current line of development is ready for review:
   1. If master has advanced beyond where it was when you started your development, pull the current head of master and merge master's changes with yours.
   1. Push your line of development to a branch in the origin repository.
   1. Ask another Melange engineer to review every unreviewed commit in your branch.
   1. Make changes and re-push to your branch, and secure re-review as necessary.
   1. When every commit on your branch has been reviewed (positively), push the (reviewed) head commit of your development branch to master, taking care to make no additional changes.
   1. Prune your development branch if it will see no further use.

 # Sample Author Commands

 ## Pulling from origin
 `git pull --no-rebase --no-commit`

 Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged.

 ## Pushing commits to a branch for review
 `git push origin <hex string of commit to be reviewed>:<review branch name>`

 ## Pushing reviewed commits to master
 `git push origin <latest reviewed commit hex string, not branch name or other alias>:master`

 This will either push your specific reviewed commits to master or fail as non-fast-forward (in which case you'll have to merge and undergo further review).

 # Rebase

 **Do not rebase.** Rebases cause us to lose review history and chronological ordering of our work. A falsely linear history just isn't worth it.

 # Reviewer Process
 If a change looks good and needs no comment, just mark it positive and hit the "submit" button. This suppresses the per-commit email thread and cuts down on mailing list noise.

 # Exceptions

 Commits made as part of the release process ("Set new Melange version number...") are exempt and may be made on master. They should still be reviewed when convenient, though.
	# Requirements

	All commits and must be reviewed by at least one Melange engineer other than the author before migration to the master branch.

	# Author Process

	When you feel that your current line of development is ready for review:
	1. If master has advanced beyond where it was when you started your development, pull the current head of master and merge master's changes with yours.
	1. Push your line of development to a branch in the origin repository.
	1. Ask another Melange engineer to review every unreviewed commit in your branch.
	1. Make changes and re-push to your branch, and secure re-review as necessary.
	1. When every commit on your branch has been reviewed (positively), push the (reviewed) head commit of your development branch to master, taking care to make no additional changes.
	1. Prune your development branch if it will see no further use.

	# Sample Author Commands

	## Pulling from origin
	`git pull --no-rebase --no-commit`

	Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged.

	## Pushing commits to a branch for review
	`git push origin <hex string of commit to be reviewed>:<review branch name>`

	## Pushing reviewed commits to master
	`git push origin <latest reviewed commit hex string, not branch name or other alias>:master`

	This will either push your specific reviewed commits to master or fail as non-fast-forward (in which case you'll have to merge and undergo further review).

	# Rebase

	Do not rebase. Rebases cause us to lose review history and chronological ordering of our work. A falsely linear history just isn't worth it.

	# Reviewer Process
	If a change looks good and needs no comment, just mark it positive and hit the "submit" button. This suppresses the per-commit email thread and cuts down on mailing list noise.

	# Exceptions

	Commits made as part of the release process ("Set new Melange version number...") are exempt and may be made on master. They should still be reviewed when convenient, though.