phabricator项目管理

本文目录一览：

• 1、如何打造团队的工程师文化
• 2、如何在mac下远程搭建git服务器
• 3、从PM的角度聊聊敏捷开发
• 4、如何在mac系统下搭建theano深度学习

如何打造团队的工程师文化

打造团队的工程师文化需要做好10件事：

1. 优化迭代速度。快速迭代的速度提高了工作积极性和兴奋度。一些工程师在面试时对他们为什么要离开公司列举了最常见的令人沮丧的原因是基础设施和繁冗流程阻碍他们部署代码或者上线功能。在组织上，快速迭代意味着给工程师和设计师的灵活性和不设限自主做日常决策。我在谷歌，任何用户可见的搜索结果改变，即使是低流量的实验，需要玛丽莎梅耶在 每周 UI 审查批准。虽然这允许谷歌保护它的搜索的品牌，但它明显阻碍创新。优化迭代速度也意味着，有明确定义的流程推出产品，而不会说花了大量时间投入后意外发 生。

优化迭代速度意味着建立持续部署以快速验证，提高测试覆盖率，减少构建和网站当机次数，快速单元测试，并鼓励大家来运行，快速增量编译 和重新加载，以缩短开发时间。持续部署，提交马上到线上特别重要。 迭代速度至少在小工程队利大于弊（线上出错的风险）。人们更兴奋看到功能和修复 Bug 是因为很快看到实时流量变化。这要比超过一周或成批的代码提交，要更容易推断和精确定位错误源的位置。

团队智慧，快速迭代的速度意 味着有强有力的领导者，帮助协调和推动团队的工作。在决定关键点上负责人需要有效地作出决定，并承诺他们的选择。借用比尔 · 沃尔什，一个领导 49 人队 3 次进超级碗的一句话，强有力的领导者需要 “承诺，引爆，恢复”，这意味着承诺攻击计划，执行它，然后看反应结果。优柔寡断团队只会导致个人努力白费。

2. 尽量自动化。

在技术讲座 “规模化 Instagram”，Instagram 的联合创始人迈克 · 克里格引 “优化最少的操作负担” 作为一个重要的教训，领导他的 13 人团队用户增长到几千万。 产品的增长意味每工程师的操作负担加重，如用户跟工程师或者特定功能跟工程师的比率。 像 Facebook 号称每个工程师支持超过 100 万的用户比例指标。

自动化解决方案和脚本去重复执行任务很重要，因为它们解放工程团队，让他们为实际产品工作。确保如有失败服务自动重启和方便快捷在流量高峰期替代是在管理大而复杂产品的明智方案。在短期内可以对应用做快速修复，而长期还是要依赖自动化测试，这需要权衡。

Etsy 的的座右铭 “衡量所有，衡量一切”。支持像开源监控和制图工具 graphite 和 statsd 突出自动化 – 即自动化必须由数据和监控驱动。如果没有监控和日志你怎么知道什么事情错了，为什么错。自动化是困难的。一个后续的座右铭是 “衡量所有，衡量一切，并尽可能自动化。”

3. 建立合理的软件抽象。

我的麻省理工学院教授和本科生研究顾问丹尼尔 · 杰克逊说的软件抽象的重要性：

“选择正确的方式，程序化自然而然地设计; 模块化就是有小而简单的界面; 新功能在不影响全局的情况下产生。要是搞错的话，程序将是一系列的讨厌的坑：接口很笨拙因为他们无法适应一些意料之外的交互，即使是最简单的改动将是很难维护 “。

是什么在谷歌让数千名工程师建立可扩展的系统，是因为他们有非常聪明的工程师像杰夫 · 迪恩和桑杰 · 格玛沃特创建了简单，但丰富的抽象，如 MapReduce 的，SSTable，Protocol Buffer 等。是什么让 Facebook 工程这么支持大规模，是因为专注于核心，同样喜欢抽象和简单，Thrift, Scribe, Hive。是什么让设计人员能够有效构建产品，Webnode，Livenode 也是基于同样的理解。

保持核心抽象的简单和减少自定义解 决方案，并增加团队熟悉度和对专业知识的抽象。日益普及系统像 Memcached，Redis，MongoDB 等系统都是降低建立定制存储和缓存系统的必要。团队重点转移到少数核心抽象，而不是分裂在很多临时解决方案，让公共库更稳健，监控更智能，性能更易理解， 测试更全面。所有这一切都有助于搭建一个简单的系统，降低操作负担。

4. 注重代码审查，编写高代码质量。

维持高品质的代码库增加了整个工程团队的工作效率。清洁代码更容易便捷发展和维护，更适应变化，不容易引入错误。健康的代码审查过程使之成为可能。

建立及时代码审查流程，不管是预提交或提交后，能有几种方法的提高代码质量。首先，知道有人会检查你的代码，提交写得不好的代码可能会辜负你的队友。那些难以维护，或未经测试的代码是一种压力。第二，代码审查也提供了评审和相互学习编写更好代码的机会。

代码审查更容易接触到其他工程团队成员，评论也带动了 a）增进一段时间内审查代码的责任感 b）允许团队成员 – 特别新手 – 观摩别人的好代码，c）加快最佳编码实践的传播。

有种说法，灵活的团队没多少时间花费在代码审查而忽视了技术债务，可以很容易地从写得不好的代码积累。 在创业早期就为了完成尽可能多的功能而忽略代码审查; 其结果是，虽然最初的产品更迅速地拥有了市场，但代码变得修改痛苦，我们花了一年多时间仅仅是改写脆弱的代码，以偿还技术债务。

谷歌预先进 行审查所有的代码，但规模较小的团队并不需要那么全面和严格，因为不是所有的代码需要使用相同的标准审查。 公司后来采用后提交的评论通过电子邮件通知核心处危险的变化。我们用 Phabricator 对所有的代码审查，大多后提交，并采用了不同的标准模型，比如控制器代码和视图代码; 对于敏感的代码或新工程师的代码，我们要么做预提交的评论或试图在几个小时被提交的代码中查看它们。

5. 保持一个尊重的工作环境。

同事之间的尊重构成开放交流的基础。靠谱的想法获得往往通过大家辩论，这种挑战也是感觉很舒服的方式。人们不爽的是重要反馈没有及时回应。

1948 年，亚历克斯 · 奥斯本概述了在过去的几十年中在工作环境中流行方法，参与者走到一起，抛开批评和负面的反馈，共同凝聚在一起不用担心被评判，头脑风暴会议。最近的心理学 研究已经开始推翻奥斯本的做法，表明在头脑风暴会议，鼓励辩论实际上避免群体思维并产生更有效的思路。鉴于这一研究，一个尊重环境变得更加重要使得攻击仅 仅是观点而不是个人。

工程往往跨越广泛的领域（系统，机器学习，产品等），而不是每个人都有相同的专业知识在每个领域。其实是一个强大的团 队应该具备，在某些领域都有能干的牛人，即使他们最终会被替代。这有时很麻烦，让一个系统工程师来评估产品工程师的能力，但在一个健康的工程师文化中尊重 这些差异很重要，并不是完全根据自己的优势来判断。

6. 建立共享代码所有权。

虽然有些人自然就成为精通代码库或基础设施的各个部分，但没有一个人应该觉得他们拥有或任何一件的唯一维护者。虽然有个人一年以上能在一些领域成为专家，在短期内有成效，这种做法最终伤害长期利益。

在组织上，共享的代码所有权提供了三个好处。首先，保持因子 8 大于 1 可以减轻压力和降低团队维护者离开的风险。这也使人很难在休息时间无忧。我清楚记得，当我夏威夷火山上徒步旅行度假时候，得到报警，因为我是公司的日志处理器的唯一维护者。

其次，共享所有权让工程师不限制在特定区域，以促进新的见解。它让工程师们从他们被困在某些项目上离开，并鼓励他在多样性项目上工作，这有助于保持工作有趣性，并提升员工学习积极性。从长远来看，它降低组织风险，一些工程师感到停滞就会决定离开。

第三，共享所有权还设置了有多个团队成员（从敏捷开发的一种技术）一起在一个高优先级的问题，必要时更迅速地完成战略目标奠定了基础。而孤立的所有权，负担通常落在一两个人。

很多工程组织犯的错误是为时过早将整个团队分成子团队。子团队会形成责任的阻碍，并很难去打破所有权的墙，因为个人可能会被其子团队的目标进行评估。 有很多小团队，我很珍惜与一些其他团队的工作机会; 他们使用敏捷开发，重心放在共享代码所有权，使得工作幸福感和生产力更佳。 初期我喜欢的一个方面是更强调项目而不是团队，让我有机会合作的项目从用户增长，机器学习，工具，推荐，分析，网站的速度，和垃圾检测。

7. 投资自动化测试。

单元测试和集成测试覆盖率是管理一个大的代码库与一大群人没有不断被破坏构建或产品的唯一可扩展的方式。自动化测试提供了对提高代码质量的大规模重构的信心 和也进行有意义的保护。缺乏严格的自动化测试，需要手动测试无论是对工程团队或外包测试团队，是容易令人害怕的，很容易陷入恐惧改善代码的文化，只是因为 它有可能破坏以前的。

在实践中，自动化测试是对持续部署工作团队成长的要求。代码库规模随着时间的推移增长，但熟悉的代码库多少会随团队成 员新人加入而减少。测试和验证是最容易被原代码作者完成，因为在他们脑子里还是清晰的，而不是被稍后几个月或几年尝试修改代码的人。鼓励单元测试是让作者 为自己工作责任。

8. 分配 20％的时间。

Gmail 是保罗 · 布赫海特的 20％的项目，第一个版本在一天搞定。 谷歌新闻，谷歌公交，和谷歌建议也是推出的 20％的项目。我用 20％的时间，而在谷歌写一个 Python 框架，使得它更容易建立搜索页面演示。而谷歌的 20％的时间在创业初期可能降低生产力，让工程师们花 20％的时间做某件事情而不是他们的产品规划上，仍然是小型工程组织的创新摇篮。

Ooyala 公司没有正式 20％的时间，我们花了一些时间写了一个命令行构建工具 Flex 和 ActionScript，加快了团队构建时间。正当 Adobe 的 Flex Builder 工具降级时候我完成了它，在工程团队超过两倍大小时该工具仍然在使用。 Atlassian 公司在尝试一年后通过 20％的时间。Facebook 后来又增加了一个 20% 时间的变化是周期性的黑客比赛 – 一晚上的事件，规则是，你可以做任何东西，除了你的正常项目的工作。

自上而下的方法对产品的规划，对公司的总体方向是重要的，不能指望从工程师中冒出很多的想法。只要工程师对他们 20％的时间和专注于什么可以有很大影响的负责，这些项目可能会导致很大的向前发展。没有官方的 20％的时间，它仍然是可能的，对工程师和设计师可能更难去尝试疯狂的想法 – 基本上都找周末或假期做。

9. 建立学习和持续改进的文化。

学习和得到充分得到挑战是心理学教授米哈里 · 米哈伊称之为 “流”，一个人是如此的完全集中在他们做的事情，他们甚至忘了时间。 直接即时的反馈能够适应更快的迭代周期。

每周技术会议给工程师分享他们的设计或者正工作的项目，创造了一个机会，工程师们为他们工作感到自豪，并学到更多工作以外的范畴。内部文档记录电子邮件服务的工作原理或如何让排名改变搜索服务，让工程师学习和探索新的东西，也很好地补充了 20％的时间。

建设学习文化的一个办法是注重指导和培训，以确保每个人都掌握基本的算法，系统和产品成功所必需的技能。工程组织的成长，花在招聘（尤其是高校招聘）越多， 更多的努力需要投入到指导和培训。一个导师每天花一个小时为一个新员工的前 4 周工作上似乎是很大负担，但投资是总时间的新员工将在一年内花费不到 1％，并能帮助到此人是否真正成功。

10. 招最好的人。

雇佣最好的人是许多其他列出的 基础。如果你认为自己是一个 B 级工程师很难有人尊重。如果你不信任他们开发产品能力，很难给别人自主权去开发产品。如果没有足够的工程经验，很难识别正确的抽象去构建系统。这很容易陷 入构建复杂结构的陷阱，又没有其他聪明人来挑战你的想法和推动你走向简单正确的道路。

在硅谷的史蒂夫 · 乔布斯说，“A 等人聘请 A 等队员。 B 等人聘请 C 等人。“关注招聘和雇佣合适的人很难，但这对工程组织有效增长很关键。黄易山，是前 Facebook 一个工程经理和总监，认为招聘必须是工程组织的首要任务，不只是管理者，工程师也如此。 他也正确地指出 “雇佣最好的” 和 “雇用你面试过的最佳人选” 的区别

在初期，我们在客户工作上不堪重负，我们很想降低我们的招聘门槛，这样我们可以聘请足够的人来做大量工作。我很高兴我们没有，因为低质量的代码和较弱的工程师团队积累技术债对团队和产品的伤害是很大的。

建立一个良好的工程文化无疑是一个大量的工作，但由此产生的工作环境是值得的。

如何在mac下远程搭建git服务器

您好，很高兴能帮助您

首先要有 ssh远程登陆的工具，比如secureCRT等

方案一 基于SSH直接搭建

Git支持的协议主要是四种：

本地: 需要文件共享系统，权限不好控制

HTTP：速度慢

SSH：同时支持读写操作，不支持匿名的读取(Git默认协议)

GIT：最快

从搭建的难易程度和特点综合筛选，最合适的还是ssh，并且大部分服务器上基本都有ssh服务，所以省去了不少麻烦。一个最基本的思路是给每一个人一个ssh帐号，这样大家就可以通过用户名和口令来访问了，但是显然这不是一个好的选择，这个做法有些多余，并且对于repo的权限很难管理。

在使用Github的时候，会利用rsa.pub公钥/私钥的方式，这样在服务端拥有用户的公钥（*.pub）之后就可以，跨过繁琐的口令，直接认证提交了，而服务端也会根据不同的用户身份，对其权限有着更加灵活的管理。因此我们也采用这种方式。

服务端

为了使远程库访问更加直观，先在服务器上创建一个名为git的账户，这样以后clone的时候就如下面的格式了：

git clone git@server:some.git

创建新的用户，创建repo等目录

$sudo adduser git

$su git

$cd ~

$mkdir repos

在HOME下的.ssh目录，如果没有则创建，创建一个authorized_keys文件，这个文件就是用来管理所有git用户的公钥的，也就是这里面的用户对于项目有着R+W的权限。

客户端

对于每一个客户端，我们需要生成一对密钥和公钥，如果是Github用户，那么.ssh目录下，一定有id_rsa.pub和id_rsa两个文件，其中第一个是系统生成的公钥，另一个是自己要保存好的密钥。如果没有的话，可以在终端执行：ssh-keygen来生成，完成后，将自己的公钥提交给管理员，这就是一个注册的行为。

完成

最后一步，管理员将团队成员的公钥添加到authorized_keys中，比如将同学susie加入：

$ cat susie.pub authorized_keys

至此，大家可以通过git@server:repos/some.git来访问公共的版本库了。

问题

安全问题，成员可以登录git用户的shell,细节权限如分支等不好控制

管理麻烦，新建repo,或者增加成员比较麻烦，尤其是修改的时候

方案二 使用Gitolite服务

Gitolite 也是基于SSH协议构建的方便管理git repo的应用，可以通过其源码安装.

安装

安装按照官方给定的文档就可以轻易的实现：

$ git clone git://github.com/sitaramc/gitolite

$ mkdir -p $HOME/bin

$ gitolite/install -to $HOME/bin

$ gitolite setup -pk YourName.pub

如果执行最后一条命令的时候，gitolite不识别，则可以通过下面两种方式解决：

将gitolite添加到PATH里面

通过$HOME/bin/gitolite setup -pk YourName.pub 执行

至此，gitolite在服务端，搭建完毕，会发现此时HOME目录下增加了一个文件projects.list和一个目录repositories,后者就是我们的版本仓库了，每当新建repo的时候，就会在其中创建。

使用

是时候说一下gitolite的管理模式了，他会创建一个gitolite-admin的repo，管理员就是通过像这个repo提交配置文件而实现对git服务器的控制的。

首先，将这个repo导入到我们的workspace：在此之前，需要配置本地的ssh,gitolite要求管理员的本地密钥和其注册公钥的名字一致，比如我们安装的时候指定 -pk后面为 admin.pub 则管理员本地需要由admin对应的私钥。我们可以通过~/.ssh/config来进行配置（注：有些系统可以用conf，Mac OSX 下无效，只能用config).

host gitolite

user git

hostname yourhostname.com

port 22

identityfile ~/.ssh/admin

这样，当我们访问gitolite的时候就会自动根据配置文件执行，配置完成后可以根据下面的命令，将gitolite-admin转移到本地。

git clone gitolite:gitolite-admin.git

克隆完成后，可以发现，gitolite-admin下面有两个目录，其中conf保存配置文件，我们可以通过编辑里面的gitolite.conf文件，管理git服务器，keydir目录保存用户的公钥pub文件。

当我们讲修改后的repo 提交的时候，gitolite就会自动的应用这些配置，管理过程就方便了很多。

配置规则

打开gitolite.conf文件可以看到其中的示例：

To add new users alice, bob, and carol, obtain their public keys and add them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively.

To add a new repo 'foo' and give different levels of access to these users, edit the file 'conf/gitolite.conf' and add lines like this:

repo foo

RW+ = alice

RW = bob

R = carol

上面的配置文件就是新建了一个repo foo，并且添加了三位项目成员，每一个人的权限不同。提交push后，管理便生效了。

可视化

我们可能会需要一个web界面来管理这些项目，我目前知道的有三种方式：

git源码中自带的组件，cgi脚本实现，使用gitolite服务

gitlab开源框架，基于ROR，新版本不再使用gitolite服务

FB开源PHP框架 phabricator，功能高端上档次

你的采纳是我前进的动力，

记得好评和采纳，答题不易，互相帮助，

从PM的角度聊聊敏捷开发

从去年年底开始负责APP的社区功能，技术实现上用可H5的形式，从APP团队中独立出来。以小团队尝试敏捷开发模式的探索，而我作为产品经理，自然也是这个敏捷项目的Scrum Master。

我们团队的构成为：

这应该算是敏捷开发中最mini的团队，而且大部分人还不是完整的一人力投入到社区工作中，包括我自己。但好在其他人额外的工作也由我这边管理，从需求排期上我可以灵活支配大家的工作排期，不影响到社区项目整体节奏。经过这快一年的磨合，我们的迭代速度从2周变为1周，也把敏捷开发流程修改践行到最适合我们团队的模式。

有一些我作为产品经理对于敏捷开发的思考，将其记录下来。

所有讲Scrum敏捷开发的文章里都很重视团队每日的站会，“今天做了什么，将要做什么，有什么障碍”的站会三个主题是为了团队每个人快读沟通当前的进度与困难，促使团队更好的协同开发，认为站会是敏捷开发中必不可少的环节。但是在施行中，站会的效率很难保证，经常变成昨日热门话题的集中闲聊会，当然也是我这个PM组织的烂。而且因为是弹性工作制，加上北京早上糟糕的交通，召集会议也花很多时间。

鉴于此，我们不再开晨会，而是直接坐在一起。每天需要同步大家进度的时候，直接转个椅子快速沟通就结束了，而且遇到问题也及时让同事提出来，大家一个转身就去看具体问题了。

另外这种从技术、产品、设计的独立团队中剖离出来的独立感，坐在一起能让团队成员有项目团队的归属感。除工作以外，大家也更熟悉生活中的彼此，能更好分担协助彼此完成项目的工作。

在公司开发流程中最常用的项目协作工具是Readmine。我个人是对传统的这类软件开发时代用的协作工具Readmine、Bugzilla……抱有无限的敌意，因为这类工具经过这么多年的更新，实在是太完善了，太大太全太复杂。并且传统项目管理工具的受众是专职的项目经理，产品经理用这类软件做项目管理太耗费时间，太容易掉到琐碎的项目管理细节中。

所以，在我们项目中采用Tower做项目管理工具。类似的看板类项目管理工具如Trello、Teambition、Phabricator、Tower……大多大同小异，找一个自己顺手习惯的就好。看板类的项目管理工具最方便的就是拖拽任务，可以在一页上看清该版本各个任务的进度。另外这类项目管理工具有更好的扩展性，有丰富的插件可以去选择性集成以提高开发效率。

在敏捷开发的流程中，产品经理需要做好项目管理的工作。而项目管理工具是必不可少的，至于如何选择每个人使用习惯差异很大，可以根据自己团队现实情况去选择。总之不要用传统的项目管理软件，因为传统项目管理工具的受众是项目经理，而不是产品经理。

我们公司没有UE，产品经理除了出需求，还需要给出交互。如果按照正规的文档流程规范，一个版本的文档写完，留给开发的时间也就不多了。至少在我们项目中，我不写文档只出交互，重要的点直接在图中文字标注。但产品的逻辑细节，我会在画交互稿的同时记录在个人的印象笔记里。好记性不如烂笔头，尽管不输出正式的文档，但产品的逻辑必须明确。毕竟后续的需求修改、测试用例都基于原始的产品逻辑，产品经理忘记自己设计的东西，无论如何都是说不过去的。

输出交互稿之后，我会单独拉上开发、测试和视觉去开一个会，具体讲一下这个需求的设计，传达本来需要我用文字写在文档中的意思。当然不写文档，不代表需求模糊，经不起其他人在会上的挑战。

会上说需求设计的最大的好处是，我能明确的用口语传达出对需求细节的感情色彩，哪儿是重点，哪儿细节体验要保证，哪儿做成什么样都行……很多是无法拆分的需求细节，但是通过言语说出来就很容易被拆分掉，更好地让开发容易理解需求重点，加快开发速度。

一般项目的需求评审一般是产品拉着各个老大来做需求评审，各个老大接了需求后会上评估下工期，会下再把相关的需求分给下面的人做。具体做事的人，往往是接到需求后再啃文档，自己理解后再去开发。总结复盘的邮件更是只在产品组内部和leader的邮箱里呆着，根本不会给到每个开发成员

而敏捷开发从需求评审阶段就必须拉上所有团队成员，产品经理要把需求场景、优先等级、用户调研……讲给所有人听。然后要在团队中达成一致，让团队所有的小伙伴都认可你的需求，并且愿意主动把这个需求做下去。版本上线后的效果也需要同步给团队的小伙伴，让大家都输出的结果都有反馈，然后也可以听听团队每个人的建议与感觉，再综合考虑及时调整产品。这些能极大强化团队的凝聚力，让每个人并非只是做自己手头的工作，更有产品的主人翁意识。

这点经验与我们项目类型有关，因为我们做的是社区类产品，很多测试的case流程必须要帐号间的互动，久而久之我们团队在测试阶段每个人都演变成了测试。

测试同事写完测试用例，等提测之后，我们所有人都汇聚在一个小会议室里。每个人分工其中的一些流程测试，快速协助测试走完case，然后快速将bug记在白板上发到群里备份，一部分需要专业手段的测试还需要测试同事专业的方法，大家协助测试的部分主要还是流程测试。快速过完之后，开发回去解bug，测试同事整理测试报告。遇到重大的bug block版本，大家就直接在会议室里讨论预案。

这种快速的团队测试能极大的提升测试效率，往往测试同事花一天才能跑完的用例，我们四个人在会议室一小时就搞定了，而且因为开发也参与了测试流程，连问题描述、复现步骤都不用写就可以直接定位问题。

这点其实是所有开发排期的都需要注意的问题，只是敏捷开发更容易暴露这个问题。这里的重要功能，并不是产品优先级上的重要，而是开发难度上的定义。因为敏捷开发的周期很短，每个重要功能上线后往往需要一定时间进行稳定。如果在排期上每个Sprint都有重要的功能，稳定上个版本与开发下个版本交叉，基本上会造成下个版本的delay。

所以在需求排期中，临近的Sprint要注意功能上的间隔。有的功能干脆就在需求排期中强制拆开，留足稳定的buffer。另外，有时候版本发不出去就不要发，不要为了敏捷而发版，那样就本末倒置啦！我们团队还有一个约定俗成的事，如果大家齐力克服困难将一个眼看需要delay的版本弄上线了，上线后必须tb大吃一顿作为奖励刺激，23333~

我们项目经过大半年的敏捷开发，无论是团队气氛还是产品数据都取得了比较好的结果。 与其说敏捷开发是一种项目管理的方法，不如说是一种切换大家工作角色的方式。让大家抛开原来的螺丝钉角色，全方位的参与到整个项目的流程中，强化主人翁意识。 让团队的每个人切实地认识到自己就是这个产品的主人，主动为产品考虑，主动协助上下游更好地完成目标。

如何在mac系统下搭建theano深度学习

方案一 基于SSH直接搭建 Git支持的协议主要是四种： 本地: 需要文件共享系统，权限不好控制 HTTP：速度慢 SSH：同时支持读写操作，不支持匿名的读取(Git默认协议) GIT：最快 从搭建的难易程度和特点综合筛选，最合适的还是ssh，并且大部分服务器上基本都有ssh服务，所以省去了不少麻烦。一个最基本的思路是给每一个人一个ssh帐号，这样大家就可以通过用户名和口令来访问了，但是显然这不是一个好的选择，这个做法有些多余，并且对于repo的权限很难管理。 在使用Github的时候，会利用rsa/sitaramc/gitolite $ mkdir -p $HOME/bin $ gitolite/install -to $HOME/bin $ gitolite setup -pk YourName port 22 identityfile ~/.ssh/admin这样，当访问gitolite的时候就会自动根据配置文件执行，配置完成后可以根据下面的命令，将gitolite-admin转移到本地。git clone gitolite:gitolite-admin.git克隆完成后，可以发现，gitolite-admin下面有两个目录，其中conf保存配置文件，可以通过编辑里面的gitolite.conf文件，管理git服务器，keydir目录保存用户的公钥pub文件。 当讲修改后的repo 提交的时候，gitolite就会自动的应用这些配置，管理过程就方便了很多。 配置规则 打开gitolite.conf文件可以看到其中的示例： To add new users alice, bob, and carol, obtain their public keys and add them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively. To add a new repo 'foo' and give different levels of access to these users, edit the file 'conf/gitolite.conf' and add lines like this:repo foo RW+ = alice RW = bob R = carol上面的配置文件就是新建了一个repo foo，并且添加了三位项目成员，每一个人的权限不同。提交push后，管理便生效了。 可视化 可能会需要一个web界面来管理这些项目，目前知道的有三种方式： git源码中自带的组件，cgi脚本实现，使用gitolite服务 gitlab开源框架，基于ROR，新版本不再使用gitolite服务 FB开源PHP框架 phabricator，功能高端上档次