特别声明：本文专为图灵社区活动“”而写，欢迎大家积极参与！
特别感谢：本文的风格照搬高翌翔的“布道体”
中讲到了企业开发的困境，其中有一点就是企业的流程和工具很难适应新的敏捷开发模式。我认为其中之一就是版本控制系统，本文就是探讨一下我是如何来推动这个改变的，也就是我的布道之旅。
【免责声明】这里不是探讨两种技术的好坏，而是如何推动变革，每个技术都有适应的场所，请勿生搬硬套。关于版本控制的选择，可以看看Martin Fowler写的
在传统企业中，版本控制系统大都采用ClearCase，因为在早期它应该提供了强大的企业应用的功能，我们企业也很早使用了。而且长久以来，在它周围建立了无数的应用和流程，同事们都觉得它是必须的了。
然而随着敏捷和开放的推动下，在有些产品用Clearcase开发碰到了很多局限，比如在家上班，远程团队开发。有人开始想到引入其他工具（svn，git）来解决，不过在大型企业中要改变这种基础的工具是很难的。
我做为一个软件开发的探索者，努力的想改变点什么，但不知从何而起。
了解分布式版本控制（DVCS）——初识道
开始考虑这个的时候是在2009年初，svn是第一个考虑的对象，因为它在开源中用的最多，和eclipse的很多项目多用它，但我总觉得缺了点什么。
恰好我有个极力推荐一个分布式版本控制工具：mercurial，说实话听了介绍不是很懂，没有眼前一亮的感觉。聊了一下，感觉和svn的分支没有多大区别，还两层提交呢。
同时他也告诉我还有其他的分布式版本控制工具git，bazaar可供选择。
不管怎么样，我了解了这块领域有了最新的技术，或许能解决我们的问题。
尝试在日常中使用分布式版本控制——初行道
为了尽快了解DVCS，我决定要在日常的开发中用用它，实践它，尽快的掌握它的关键。
由于Geek对mercurial很熟，我就踏踏实实的用mercurial用了两个星期，不懂就问他，顺便查查资料去比较一番。
wooh,wooh，DVCS真是很神奇，很好用，特别对我（作为码农）的胃口，感觉DVCS天生是为软件开发用的。
在同一时刻，我又比较深入的看了看其他的系统如git，发现git的生态圈更好一点。在软件开发中，生态圈会决定将来这个工具的发展趋势。
如eclipse插件开发邮件中开始讨论并决定用git替代svn。
git有很多的书可供选择（如 ），的内容也极其丰富。
也漂亮得提供git的支持。补充一下，那时候和github还在同一个水平线上。也还不支持git，只有mercurial和svn。
通过这些实践和了解，发现DVCS：git很适合我们所在的企业产品软件开发。
宣扬和推广分布式版本控制——初布道
要在企业中换一个版本控制工具难度非常大，所以必须要造势，也就是此处的布道，我采用了下面的方法：
每月我们都有固定学习新东西的时间，我就推荐了mercurial、git两个课程，让大家共同来学习，了解它。顺便我要看看开发者对它的接受程度，有趣的是，水平越牛的人越是喜欢它，纷纷过来问什么时候能在产品开发中用上git。
除了开发者，管理者和其他的使用者（配置管理的同事）的想法也很重要。我经常抓住机会和这些人聊DVCS ，聊git，给他们介绍，看看他们有什么想法。当然他们会不同意我的观点（有强势的，有委婉的），我就试图去说服他们，挖掘出推动这个变化的关键因素。
慢慢的我就开始得到了很多如何推动这个变化的材料，以及说服他们的模板（哈哈对症下药）。
详细研究版本迁移——再识道
开发者想使用分布式版本控制的呼声越来越高，管理者也开始认真考虑了。
在企业中，改变所需要的研究评测报告（word，ppt)是必不可少的了，这也给了我一次重新认识集中式和分布式版本控制的过程，我花了更多的时间去想这个改变对企业带来的好处。实际上开发者有时候不会考虑到整个软件开发的所有方面，如安全，持续集成等等。报告的大致框架是：
现在问题是什么？
什么是DVCS，git是什么？
能改变什么？带来的好处？
如果变化，计划是什么？
研究报告就不细讲了，太技术了，而且有点商业机密，哈哈。
这一期间，使我更详细的了解了git和对企业可能的影响（有好的，有坏的），并制定了相应的对策。
开始在小范围实施——再行道
布道需要耐心和机遇，机缘巧合，迁移到git的建议比较顺利的被管理层接受了。（我的报告难得那么顺利通过的）。
然后就是要去认认真真的实施了，这不是一个小问题，既然是软件开发，来不得半点的马虎，细节决定一切。而且实施的好坏还涉及到自己的面子问题，讲笑了。
企业中一般从小范围开始实施，成功了才推广，下面是我们的一些实践。
我们用作为git服务器，架好试验平台，在一个小项目中开始尝试。
人手一本git的书，安排git入门培训，提高驾驭git的能力。
不断收集资料，提高对git的认识。
还好基本上没有出大的差错，虽然有蛮多技术难点的，不过最后都解决了。通过小范围的使用推广，我们的技术储备也加强了（特别是配置管理的人），对下一步的全面实施更有信心。
推广，并引入gerrit做代码审查——再布道
早期我们用的是gitolite来架git服务器，它很不错。不过后来发现更好用，后来就切换过去使用了。这一点很重要，要不断探索这些新技术，争取在大规模推广前，用一个最适合的工具，否者一用上，在企业中就很难改变了。
git开始在更多团队和更多产品中使用后，我们不断加强知识的培训，而且把相关的系统（如持续集成）都迁移到git上去。一切都还不错，只是git比想象中还复杂一点。
因为gerrit有很强大的代码审查（code review）功能，不久以后这个功能也用上去了，代码提交的质量一下子上了一个档次，这是开始推动git变革时没有想到的。
（此处引用高翌翔写的“布道体”结束语）
子曰：己所不欲，勿施于人。因此，布道者在布道前，须识道、行道，而布道时应谨记“己之所欲，慎施于人”，身教重于言教，务必身体力行、以身示道！
我的识道、行道、布道之旅没有终点，希望能结识更多的同路人 ;-)
本文也是我用git记录在上的，你可以看到每次的变化。
如果对此文有兴趣，帮忙顶一下，别忘了
，希望有机会有人能帮我推荐到QConf 2012中去分享，到时我们可以探讨的更多。
顺便推荐的，国内少有的好书。
不知道是否参考了 那本 修改代码的艺术，呵呵
写得非常好。对照一下《布道之道》，您可能会发现很多理论已经被您用到实战中了：原来XX就是激情燃尽型啊！原来用的就是“展示技术”、“建立信任”这些技巧啊！
Larry布道的水平绝对很高 :)
技术人员喜欢新的酷的技术，充满一腔激情，这很常见，但布道不是简单通过技术就能解决的问题，更何况还有很多技术人员全局观很差，只看到亮点，没看到地雷。
Larry的经验非常值得学习，先自己学习，对比各种工具，然后鼓动周围的人都去了解，接着分析自己环境下实实在在的问题，小范围实施，逐步获得管理层的信任，最后再全面推广实施，这其中每一步都非常的重要。这些需要激情，更需要细心，耐心。
感谢Larry的分享。
P.S. 图灵本该抛弃门户之见，只要书好，推荐竞争对手的书又何妨？要虚心学习对手出优秀的原创书。
在图灵推华章的书那，哈哈。多谢分享！看了《布道之道》这本书之后相信你的布道之旅一定会越来越顺畅的。&&&&&&正文
如何提交代码给openstack
摘要：如果想为openstack做贡献，最好的方法就是帮助社区完成blueprint或者做bugfix。代码的提交需要遵循社区的一些基本要求...
如果想为openstack做贡献，最好的方法就是帮助社区完成blueprint或者做bugfix。代码的提交需要遵循社区的一些基本要求，以下内容是去年对openstack社区的参与过程中的一些总结。流程 & &注册一个openid & &申请个人CLA证书 & &申请公司CLA证书(个人不需要做本步骤) & &更新贡献者列表，公司栏写上所属公司的名字 & &加入OpenStack Contributors组(必须)和OpenStack组 https://launchpad.net/~openstack-cla/+join(必须) & &设置SSH Keys（复制本地~/.ssh/id_rsa.pub的内容即可） & &认领一个blueprint/bug(这步可以跳过) & &git clone代码到本地，配置user.name和user.email和openid中登记的一致 & &在期限内修改，并通过所有测试(不通过测试一定会被拒)。代码的一个基本的要求是要符合 PEP8 规范。 & & & &|__如果超过期限，去界面上点击“Restored”按钮即可 & &用git review命令提交审核 & &等待评审结果 & &按照评审要求修改代码，用git commit …. -amend提交修改 & &再次git review直到成功测试要求[plain] import库的名称需要按照字母顺序排列
pep8检测：
sudo apt-get install pep8
~/nova$ pep8 .
sudo pip install nose
~/nova$ nosetests .
~/nova$ sudo ./run_tests.sh [api/xxx/xxxx.py]
例如：./run_tests.sh test_db_api
tempest-devstack：
./exercise.sh注释要求格式分为三部分，最前面一行是本地修改的简述，后面空一行之后写本次修改的详细描述，后面再空一行写本次修改对应的bugid或者bpid，然后紧接着写changeid。 系统会根据注释中的Change-Id去判断这个提交是属于那个bp的，fixbug和implement blueprint要写在changeid前面一行。[plain] Implement bp:efficient-limiting.
1.add limit param to db.instance_get_all_by_filters()
2.execute limit before sqlarchmy get_all()
Fixes: bug #1003373
Implements: blueprint xxxxxxxxxxx
Change-Id: Iea3eeb7bd624506aafc更新要求在执行git review之前，应该确保review是最新的，使用如下命令更新当前代码到最新版本：[plain] git fetch origin master
git rebase FETCH_HEAD
git commit --amend
git review如果rebase的时候发生冲突，应该手工解决冲突之后执行git rebase --continueF.A.Q.[Q]由于服务器的原因导致提交review后的代码测试失败。[A]对这个patch执行review，如果是SmokeStack，输入reverify，如果是Jenkins，输入recheck即可让其重新进行测试[Q]如何在家继续修改[A]在公司提交patch去review后，在家继续进行修改，可以1. 本地执行 & & git-review -d review_number & &如，git-review -d 12859 & &这个步骤会校验ssh-key或者2. 将Jekins上的改动merge到本地。 & &在review按钮附近有按钮
全国校区查询
新手入门点击榜
新手入门最新文章
官方新版意见收集
*您的积极反馈是我们前进的动力
官方新版意见收集
提交成功，感谢您的反馈。
我们会认真阅读和考虑每个用户的反馈。4005人阅读
1.&创建一个&账号，加入社区。
2.&配置你的：
git&config&--global&user.name&&Firstname&Lastname&
git&config&--global&user.email&&your_&
Ubuntu或者其他大部分Linux系统:
pip&install&git-review
Ubuntu&Precise&(12.04)&或者以后的版本包含git-review,像其他软件一样安装即可。
apt-get&install&git-review
Fedora&16&以后,&git-review也包含在发行版本中，像其他软件一样安装即可。
yum&install&git-review
openSUSE&12.2以后版本，也包含在发行版本中，像其他软件一样安装即可
zypper&in&python-git-review
4.&工程设置：
获取项目代码
git&clone&git:///openstack/nova.git
检查检查是否可以提交代码
git&review&-s
如果之前没有增加过远程仓库
git&remote&add&gerrit&ssh://&username&@review.openstack.org:29418/openstack/nova.git
5.&正常工作流程
获取仓库最新代码
git&remote&update
git&checkout&master
git&pull&--ff-only&origin&master
当你要开发一个特性或者修改一个，创建一个分支，在这个分支里边完成你的修改
git&checkout&-b&TOPIC-BRANCH
6.&提交修改
提交信息里边需要写上你的连接和号
Adds&keystone&support
...Long&multiline&description&of&the&change...
Implements:&blueprint&authentication
Fixes:&bug&#123456
Change-Id:&If712ae2adfc0bb0bb657
git&commit&-a
如果是上次提交的一个
git&commit&--amend
git&review
注：Gerrit根据change-Id识别你的patch，出于各种原因，你原来提交代码的本地仓库坏掉，这时你可以从Gerrit上取下你的patch，由于这时你不能再git commit -a --amend, 你可以在commit log的最下边写上你原来的Change-Id,还是可以提交到你原来的change上，生成一个更新的patch。
7.&代码评审
正确提交后，会在&生成一个页面。如果你的还没有完全完成，你可以把你的设置为”working&in&progress”。一旦完成，你就可以增加评审人来评审你的代码。支持在线的，可以针对你提交的每一个文件，到对应的行上边去增加评审意见。一旦有人提交评审意见，你需要尽快的给出你的意见，然后通过”Review”里边的“”发布你的意见，这样别人就可以看到你的修改情况了。
如果别人的评审意见你采纳了，这时你修改了你的代码。你需要重新再上传一个，让评审人再次评审。
git&commit&-a&--amend
git&review
直到没有人再给出评审意见。这时一般的核心开发人员会批准你的进入正式仓库。
如果在你开发过程当中，仓库里边的代码有人提交了新代码，那么你再提交新的的时候后出新冲突，这时你要
git&checkout&master
git&pull&origin&master
git&checkout&TOPIC-BRANCH
git&rebase&-i&master
8.&增加依赖
如果你需要在别人提交的的基础上工作
#fetch&config
git&fetch&https://review.openstack.org/openstack/nova&refs/changes/16/10816/9&&&&git&checkout&FETCH_HEAD
git&checkout&-b&SOMEBRANCHNAME
git&review&-R
注意：选项十分重要，否则初始的提交会被错误的修改
如果你依赖的提交的代码有更新，这时你要
#&check&out&the&parent&commit&of&the&depended&commit.&SHA1&is&the&commit&id.&
git&checkout&-b&aNewBranch&SHA1
#&cherry&pick&the&depended&commit
git&fetch&https://review.openstack.org/openstack/nova&refs/changes/80/28880/40&&&&git&cherry-pick&FETCH_HEAD
#&cherry&pick&your&last&commit
git&fetch&https://review.openstack.org/openstack/nova&refs/changes/28/30028/6&&&&git&cherry-pick&FETCH_HEAD
#&Do&the&revisions
git&commit&-a&--amend
#&submit&for&review
git&review&-R
————————————————————————————————————————————————————————
Openstack相关技术交流请加群：
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：201428次
积分：3061
积分：3061
排名：第4338名
原创：88篇
转载：42篇
评论：56条
码农一枚, 一直在世界500强公司混饭.持续关注web前后端,mobile web,高并发和云计算相关技术
(1)(1)(3)(2)(1)(3)(1)(7)(2)(1)(4)(1)(1)(1)(2)(1)(2)(3)(2)(1)(1)(1)(3)(1)(3)(1)(1)(1)(1)(2)(1)(2)(1)(3)(4)(4)(12)(4)(3)(2)(6)(7)(1)(5)(7)(10)(3)(1)使用git push命令提交到gerrit
Gerrit是一款被Android开源项目广泛采用的code review(代码审核)系统。以前一直以为必须用repo上传，今天因为偷懒，想用git直接推上去，没想到居然成功了。。
先尝试直接用git push http://review.xxx.xxx/xxx/xxx master:master ，发现返回rejected，查看通知发现是不支持直接推送到主分支。
那么怎么办呢？当时没仔细看清楚通知，试了好多分支名称都不能推送，最后发现，通知告诉我要推送到refs/for下面的分支。
这样就容易了：
git push 远程地址 本地分支:refs/for/远程分支
轻松搞定。
标签(Tag):
------分隔线----------------------------
------分隔线----------------------------