<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Fwolf's Blog &#187; rule - Fwolf's Blog</title>
	<atom:link href="http://www.fwolf.com/blog/post/tag/rule/feed" rel="self" type="application/rss+xml" />
	<link>http://www.fwolf.com/blog</link>
	<description>随心·随意·随缘·努力～</description>
	<lastBuildDate>Sun, 29 Aug 2010 14:52:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>[Git]初学者注意事项</title>
		<link>http://www.fwolf.com/blog/post/446</link>
		<comments>http://www.fwolf.com/blog/post/446#comments</comments>
		<pubDate>Tue, 04 Aug 2009 13:57:05 +0000</pubDate>
		<dc:creator>Fwolf</dc:creator>
				<category><![CDATA[Svn/Git]]></category>
		<category><![CDATA[git]]></category>
		<category><![CDATA[newbie]]></category>
		<category><![CDATA[rule]]></category>
		<category><![CDATA[tips]]></category>

		<guid isPermaLink="false">http://www.fwolf.com/blog/?p=446</guid>
		<description><![CDATA[实在是受不了有些人的 Git 提交，费大力气“回滚”，遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。 和源码无关的东西，尽量不要进仓库 不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。 测试时上传的文件，测试时的临时文件，统统不要 对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外 编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要 对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了 图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理 对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极 使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库 不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线 尽量采用相对小、相对独立的提交 Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。 当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 linux kernel 开发文档中也有提到。 当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。 注释格式 格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。 Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。 我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质： Add something Bug [fix&#124;found]: describe the bug or [...]]]></description>
			<content:encoded><![CDATA[<p>实在是受不了有些人的 Git 提交，费大力气“<a href="441">回滚</a>”，遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。</p>

<h3>和源码无关的东西，尽量不要进仓库</h3>

<p>不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。</p>

<ul>
<li>测试时上传的文件，测试时的临时文件，统统不要</li>
<li>对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外</li>
<li>编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要</li>
<li>对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了</li>
<li>图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理</li>
<li>对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极</li>
<li>使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库</li>
<li>不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线</li>
</ul>

<h3>尽量采用相对小、相对独立的提交</h3>

<p>Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。</p>

<p>当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 <a href="http://wiki.zh-kernel.org/doc/%E5%A6%82%E4%BD%95%E5%8F%82%E4%B8%8E_linux_%E5%86%85%E6%A0%B8%E5%BC%80%E5%8F%91">linux kernel 开发文档</a>中也有提到。</p>

<p>当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。</p>

<h3>注释格式</h3>

<p>格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。</p>

<p>Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。</p>

<p>我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质：</p>

<ul>
<li>Add something</li>
<li>Bug [fix|found]: describe the bug or fix.</li>
<li>Chg something</li>
<li>Del something</li>
<li>Enh some treatment</li>
<li>New something</li>
<li>Tmp for some cause</li>
</ul>

<p>为了保持语法通顺，也可以采用前三个字母后面加冒号，后面有啥写啥的方法。</p>

<p>最后，我觉得，能够遵守行业规范和团队约定，主动养成良好习惯，应当是鉴别人才的一项重要因素。</p>

	Tags: <a href="http://www.fwolf.com/blog/post/tag/git" title="git" rel="tag">git</a>, <a href="http://www.fwolf.com/blog/post/tag/newbie" title="newbie" rel="tag">newbie</a>, <a href="http://www.fwolf.com/blog/post/tag/rule" title="rule" rel="tag">rule</a>, <a href="http://www.fwolf.com/blog/post/tag/scm" title="Svn/Git" rel="tag">Svn/Git</a>, <a href="http://www.fwolf.com/blog/post/tag/tips" title="tips" rel="tag">tips</a><br />

	<h4>Related posts</h4>
	<ul class="st-related-posts">
	<li><a href="http://www.fwolf.com/blog/post/448" title="Git 合并 patch 时的冲突处理一例 (2009-08-25)">Git 合并 patch 时的冲突处理一例</a> (0)</li>
	<li><a href="http://www.fwolf.com/blog/post/300" title="针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS） (2007-03-18)">针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS）</a> (3)</li>
	<li><a href="http://www.fwolf.com/blog/post/410" title="用ssh打通反向隧道，内网也可对外提供服务 (2008-07-10)">用ssh打通反向隧道，内网也可对外提供服务</a> (2)</li>
	<li><a href="http://www.fwolf.com/blog/post/127" title="利用SVN更新网站 (2006-01-19)">利用SVN更新网站</a> (7)</li>
	<li><a href="http://www.fwolf.com/blog/post/377" title="你最希望在哪里看到TIPS？ (2008-01-10)">你最希望在哪里看到TIPS？</a> (5)</li>
</ul>

]]></content:encoded>
			<wfw:commentRss>http://www.fwolf.com/blog/post/446/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
