CodeReview.wiki - wiki - Git at Google

 #summary Procedure for Melange Code Review.
 #labels Contents-Draft

 = 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:
   # 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.
   # Push your line of development to a branch in the origin repository.
   # Ask another Melange engineer to review every unreviewed commit in your branch.
   # Make changes and re-push to your branch, and secure re-review as necessary.
   # 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.
   # 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.
	#summary Procedure for Melange Code Review.
	#labels Contents-Draft

	= 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:
	# 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.
	# Push your line of development to a branch in the origin repository.
	# Ask another Melange engineer to review every unreviewed commit in your branch.
	# Make changes and re-push to your branch, and secure re-review as necessary.
	# 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.
	# 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.