<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:series="http://organizeseries.com/"
		>
<channel>
	<title>Comments on: How To Make Your Team&#8217;s Code Better</title>
	<atom:link href="http://www.brandonsavage.net/how-to-make-your-teams-code-better/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brandonsavage.net/how-to-make-your-teams-code-better/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=how-to-make-your-teams-code-better</link>
	<description>The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC.</description>
	<lastBuildDate>Wed, 15 May 2013 14:54:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.2-alpha</generator>
	<item>
		<title>By: Mute</title>
		<link>http://www.brandonsavage.net/how-to-make-your-teams-code-better/#comment-7085</link>
		<dc:creator>Mute</dc:creator>
		<pubDate>Sun, 03 Feb 2013 10:02:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=2057#comment-7085</guid>
		<description><![CDATA[We have been using phabricator (http://phabricator.org) and its really really good. The arcanist workflow and cli tool makes working and reviewing much easier, for us it worked better than github.

If anyone is considering making code reviews the cornerstone of their development process I would highly suggest they give it a try.

A basic example of the workflow would be:

git checkout -tb private/mychange
...do changes
git commit -am&quot;blah&quot;
arc diff (creates a review request)
... wait for review, when its accepted
arc land --squash (apply the change to master and squash the commits)]]></description>
		<content:encoded><![CDATA[<p>We have been using phabricator (<a href="http://phabricator.org" rel="nofollow">http://phabricator.org</a>) and its really really good. The arcanist workflow and cli tool makes working and reviewing much easier, for us it worked better than github.</p>
<p>If anyone is considering making code reviews the cornerstone of their development process I would highly suggest they give it a try.</p>
<p>A basic example of the workflow would be:</p>
<p>git checkout -tb private/mychange<br />
&#8230;do changes<br />
git commit -am&#8221;blah&#8221;<br />
arc diff (creates a review request)<br />
&#8230; wait for review, when its accepted<br />
arc land &#8211;squash (apply the change to master and squash the commits)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Ploch</title>
		<link>http://www.brandonsavage.net/how-to-make-your-teams-code-better/#comment-6883</link>
		<dc:creator>Thomas Ploch</dc:creator>
		<pubDate>Fri, 25 Jan 2013 06:54:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=2057#comment-6883</guid>
		<description><![CDATA[I hav introduced the GitHub PR workflow with bi-weekly review of critical patches. The best thing that you forgot is that you can trigger automatic builds for PR commits on your company&#039;s CI Server.]]></description>
		<content:encoded><![CDATA[<p>I hav introduced the GitHub PR workflow with bi-weekly review of critical patches. The best thing that you forgot is that you can trigger automatic builds for PR commits on your company&#8217;s CI Server.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brandon Savage</title>
		<link>http://www.brandonsavage.net/how-to-make-your-teams-code-better/#comment-6876</link>
		<dc:creator>Brandon Savage</dc:creator>
		<pubDate>Thu, 24 Jan 2013 19:36:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=2057#comment-6876</guid>
		<description><![CDATA[Nits are small problems in the code. Typically nits can be resolved without a second review. For example, if you&#039;re writing Javascript and are inconsistent about semicolon use, the reviewer might tell you to make that consistent and approve it &quot;with nits&quot; meaning &quot;with small changes that don&#039;t need a second review.&quot;]]></description>
		<content:encoded><![CDATA[<p>Nits are small problems in the code. Typically nits can be resolved without a second review. For example, if you&#8217;re writing Javascript and are inconsistent about semicolon use, the reviewer might tell you to make that consistent and approve it &#8220;with nits&#8221; meaning &#8220;with small changes that don&#8217;t need a second review.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cordoval</title>
		<link>http://www.brandonsavage.net/how-to-make-your-teams-code-better/#comment-6875</link>
		<dc:creator>cordoval</dc:creator>
		<pubDate>Thu, 24 Jan 2013 19:35:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=2057#comment-6875</guid>
		<description><![CDATA[what is nits?]]></description>
		<content:encoded><![CDATA[<p>what is nits?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk: basic (Feed is rejected)
Page Caching using disk: enhanced (User agent is rejected)
Object Caching 523/543 objects using apc
Content Delivery Network via Amazon Web Services: S3: brandonsavage-net-files.s3.amazonaws.com

 Served from: www.brandonsavage.net @ 2013-05-22 13:21:05 by W3 Total Cache -->