Posts

安装 下载安装后, 需要更新到最新版本 不更新可能会遇到一些奇葩问题 如果能直接更新或者翻墙更新的, 请直接更新 不能更新的, 请参考下列文章手动更新 http://www.cnsecer.com/842.html http://blog.csdn.net/hil2000/article/details/11395485 关键命令 java -classpath AI-<old-edition>-<new-edition>-patch-<os>.jar com.intellij.updater.Runner install . 新建项目 新建一个项目时, 视选择的 SDK 版本, 可能会失败, 原因是包不全 打开 SDK Manager, 勾选需要的包, 点击 Install X package[s]… 注意: 接受协议时可能需要在弹出的对话框里逐个接受, 才能一并下载 模拟器 以下问题仅限于 windows, Mac 用户可以直接放弃模拟器… 运行模拟器失败, 需要把 X盘/.android/avd 拷贝到 C盘/用户目录/.android 下 运行模拟器慢, 需要下载和安装 intel x86 emulator, 创建 avd 时也要选这个 用 SDK Manager 下载 intel x86 emulator 和对应的 rom 注意: 下载 emulator 后需要安装, 可执行文件在 sdk/extras/intel 中 数据目录 Android Studio 目前还不太稳定, 偶尔折腾, 甚至需要把数据目录清空 下面的内容摘自 Intellij 官网, 只要把路径换成 AndroidStudioPreview 即可 Mac ~/Library/Application Support/IntelliJIdeaXX contains the catalog with plugins. ~/Library/Preferences/IntelliJIdeaXX contains the rest of the configuration settings. ~/Library/Caches/IntelliJIdeaXX contains data caches, logs, local history, etc. These files can be quite significant in size. 9.0+ ~/Library/Logs/IntelliJIdeaXX contains logs Windows ~\.IntelliJIdeaXX\config that contains user-specific settings. ~\.IntelliJIdeaXX\system that stores IntelliJ IDEA data caches. Update@2015.04.13: Android Studio 在升级到 1+ 之后奇葩问题少多了 Update@2016.03.10: 模拟器建议使用 Genymotion

常用命令 find find . -name "*.xyz" find . -name "*abc*" -delete grep grep -i "abc" * # 忽略大小写 grep -R "abc" . wc wc -l find -name "*.java" # 统计 java 代码行数 权限 chmod u+x <file> # 设为可执行文件 chown <name> <file> chown -R <name> <dir> chgrp ... # 格式同 chown 系统工具 ssh ssh-add -D删除所有记住的key 解决 Mac 下所有使用过的 key 都会被记住，删除 key 文件没用的问题 链接库 查看链接库是否缺失: ldd <可执行文件> 修改系统加载库 vim /etc/ld.so.conf /sbin/ldconfig

坦诚 信任（支持） 尊重 包容（耐心）

概述 这本书并没有告诉我们应该确立什么样的人生目标, 但书中的观点可以帮助我们衡量目标的可行性, 并关注实现目标的过程中可能发生的问题 目标: 资源•应用流程•价值取向 资源是 Ta 所利用的东西 应用流程是 Ta 做事的方法 价值取向是 Ta 做某件事的动机 -> 用于评估什么样的目标可以实现, 什么样的目标遥不可及 衡量目标的可行性: 资源是否足够, 如果不够, 可能需要一个更短期的目标来增加资源 实现目标的方法已经有了吗? 可能没有, 那么需要 “根据机遇权衡计划” 目标是否符合你的价值取向, 如果不符合, 那么可能需要放弃这个目标 每天都会面临的基本挑战: 接受哪些信息 采纳哪些建议 忽视哪些问题 去做哪些事情 -> 这些挑战归结为: 如何选择 目标 - 选择 所谓目标, 虽然分长期和短期, 却依然很难直接指导具体的选择 相反, 选择的过程往往体现了 “资源•应用流程•价值取向” 这三要素 实现目标过程中可能会发生的问题: 重点不明确, 要关注你的价值取向中最重要的那部分 “根据机遇权衡计划” 既然是重点, 就要分配资源 战略: 重点•根据机遇权衡计划•分配资源 战略, 是指为实现某种目标而制定的大规模, 全方位的长期行动计划 战略是长期的事情, 短期的事情不能通过战略搞定, 但应符合战略需要 重点 重点是你做决策时的核心标准 薪水是一个基础因素, 不是动力因素 工作满意和没有不满是两回事 权衡 “哪些假设条件需要得到验证, 才能说明这个战略有效” 根据机遇权衡计划的重点是小成本尝试和拥抱变化, 是一个情况多样, 难以控制的连续过程, 很可能不是一开始就想到的 没有哪个方法一经提出就更好或更糟, 而是要根据你走到哪个阶段来确定 分配资源 任何一个战略 - 不论是企业战略还是个人生活战略 - 都是从数百次日常决定中产生的, 它是关于如何安排时间(人)和金钱(物)的决定 生活中的每一个有关如何分配时间盒金钱的决定, 都表明了你真正在乎的是什么 你可以尽情地谈论自己的生活, 谈论有什么清晰的目标和战略, 但是如果你投入的资源和你的战略方向不一致, 这些谈论都毫无意义 如果最终不能有效实施, 你的战略只能是一个良好的愿望 -> 如果家庭是重点, 就要家庭建设上分配资源 我的目标 我的目标是帮助家人(包括自己)过上满足的生活 谈 “幸福(的生活)” 太虚幻, 说 “满足” 比较实际 满足某些欲望并不能真的让人满足 为了生活得满足, 我需要更有竞争力, 更有效率; 所以 重点是生活 重点 生活包括兴趣(工作), 收入(工作), 家庭 兴趣(工作)使生活有成就感? 家庭也能使生活有成就感, 但我还是不愿意放弃兴趣(工作)的成就感 收入(工作)让生活更有质量 家庭是生活的保障 权衡 兴趣需要投入时间 收入的多少虽然不直接与时间发生关系, 但间接需要投入时间去争取(比如加班) 家庭建设需要投入时间, 可能还需要人脉 人脉需要时间, 也需要金钱? 目前金钱不是关键问题, 如果真的是关键, 也拿不出来… 持续性是生活中潜在的重要因素, 也是人的基本需求(安全感) -> 当前战略的主要问题是如何分配时间 分配资源 兴趣: 4hr 收入: 4hr, 包括理财 学习是支撑兴趣和收入的基础 家庭: 1~1.5hr 人脉: 0.5~1hr 身体是一切的基础: 1hr 关于家庭 好钱和坏钱 在事业刚起步阶段, 你或许还不知道公司策略是否能够成功, 你必须耐心等候公司成长, 同时把目光放在获利上面; 如此一来, 就要用最少的资金找到一个可行的策略, 不至于花了很多钱才知道走错了路; 如果投入资金之后, 急于看到成长而非获利, 则是 “坏钱” 在所有成功的企业当中, 有93%都必须改变最初的策略; 也就是说一定会有拐点, 所以需要提前准备; 准备的方式则是投入 “好钱” 家庭生活会有类似的问题, 同样需要提前准备, 投入"好钱"; 常见的问题是对孩子的教育 奶昔是被雇佣来做什么的 学校是被雇佣来做什么的: 获得成功的感觉, 每天都会有朋友 你是被雇佣来做什么的 -> 不要将未来外包出去 家庭文化 家庭文化是父母与孩子共同价值取向的保证 文化, 是人们朝着一个共同的目标一起工作的方式, 这种方式一直以来被大家所沿用并且一直行之有效, 以至于人们根本不会想到要以另一种方式去做事 特定文化一经形成, 人们就会自动地区做要取得成功需要做的事 问题出现时, 要做的不仅仅是解决问题本身, 还要在解决问题的过程中明确什么事重要的, 在这个过程中形成了对价值取向的理解, 并学会如何去实践这一价值取向 -> 文化是在 处理问题的过程和做选择时的价值取向被一个组织不断重复使用, 且被证明有效 的基础上形成的 一个组织的文化是否健康, 需要看该组织的成员需要选择如何去做一件事情时, 他们的选择是不是组织的文化所要求的? 收到的效果是否也符合组织文化的要求? 我的父母没为我做的事 孩子们在成长过程中很少有机会负担重要的责任, 也很少有机会能为自己或他人解决复杂的问题 “我不害怕面对这个问题, 我相信自己能解决它”, 这样的自信不是来自丰富的资源, 而是来自完成某件困难且重要的事情 我们将孩子保护起来, 让他们远离生活中出现的各种问题, 但是却无意中阻止了孩子掌握成功所需的 “应用流程” 和 “价值取向” 孩子们在自己准备好学习时才能学到东西, 而不是在我们准备好教导他们的时候 孩子在各种 “经验学校” 中学到了什么, 是比奖励或奖品更能保证他们在外面世界的冒险中取得成功的关键 其它 第一代必须要辛苦一些, 不过 “要与人交流” 这件事情应该与是否第一代无关 第一代只是资源匮乏一些, 应用流程与价值取向方面还是一样的, 都要靠实践 总结 资源•应用流程•价值取向 -> 目标 是确立目标的过程 重点•根据机遇权衡计划•分配资源 -> 战略 是实现目标的过程 价值取向和重点决定了方向, 应用流程和权衡决定了成败, 资源分配是杠杆

代码风格 代码是给人看的, 偶尔也在机器上跑一跑 代码应该越写越少: Write Less Do More 所有源代码文件(包括 html/css/properties/readme 等)均为 utf-8 无 bom 格式, unix 换行 禁用tab, 所有源代码文件一律使用 4 空格缩进 Java Java Code Conventions Java编码规范(中文版) 内部规范 第三部分 每行不超过 120 字符, 一个文件不超过 600 行 愿意遵循每行不超过 72 或 80 字符的也可以, 但不超过 120 是必须的 第四部分 再次强调每行不超过 120 字符, 一个文件不超过 600 行 换行是检验代码可读性的重要标准 第六部分 一行声明一个变量 第七部分 语句块即使只有一行也要有括号 尤其是 if 语句! 第九部分 类名为首字母大写格式 包名均为小写, 视觉上应为一个倒置的域名, 比如 com.domain.codename 常量为全大写, 下划线分隔 第十部分 善用 TODO, XXX, FIXME 其它 避免 magic number 禁用 System.out.print, 使用 logger 如果可能, 避免使用 ++, 无论是前 ++ 还是后 ++, 而是用 += 1来替代 文件结构: 将功能和方法分为命令和查询两类, 并将两者分别放在一起 也可以分成更多类, 比如 override/implement/public/private/getter/setter 等 定义 code template 是个好办法, 但关键还是在于所有人都能坚持遵循 包结构: 包内文件不超过 10 个, 接口的实现要放在对应的 impl 目录下 Singleton (helper): 需要初始化 静态函数集合 (utils): 不需要初始化, 或者有瞬间又无异常的static初始化 防御 警告就是错误! 报告所有的异常, 传播不能处理的异常, 禁止空 catch, 即使是临时这样做也不行! 在异常发生之前使用断言, 可以避免更严重的问题(比如数据不一致) 测试 单元测试就是最可信的文档 刚刚开始 TDD 时要用最简单的方式编写 TestCase, 而不是不断引入新的类, 否则你会强迫自己保留和使用它们 像重构代码一样重构测试 测试用例以 Test 开头, 测试一个类用 TestClassName, 测试一个包用 TestPackageName (为了遵循类命名规范, 包名需要首字母大写) 调试 善用 debug 模式, 而不是 log, 更不是 print 但是, 在运行着的系统中 log 还是很有用的, 所以 log 中要展示有用的信息 实验用例以 Run 开头, 后面同测试用例, 通常每个实验用例都只有一个 main 函数, 主要用来做实验 Html/Css/Javascipt html 的 id 为驼峰格式, 形如 abcXyz html 的 class 为全小写, 形如 abc-xyz

什么是 wiki wiki 是一种网络应用 遵照一定的格式, 使用纯文本书写, 输出 html 文档 方便的内链接, 在多个内部页面之间跳转 多人编辑, 支持版本历史 如何创建一个 wiki 页面 访问一个不存在的 url, 建立一个新的页面 比如 /APageDoesNotExist 页面的名字必须是 首字母大写 的, 首字母大写的名字可以被 wiki 识别为内链接 点击 “创建页面”, 编辑 书写语法见 /WikiFormatting 编辑完点击 “预览”, 查看输出的 html 是否符合预期 如果没问题, 点击 “提交改动”, 即生成一个新的 wiki 页面 添加附件 wiki 允许增加附件 打开一个存在的 wiki 页面, 点击页面底部的 “附件” 选择文件并上传 如果可能, 尽量书写一份 wiki 文档而不是上传一个 word 文档作为 wiki 的附件 规划 wiki 文档的层次结构 wiki 中使用 = 到 ====== 代表 h1 到 h6 标签, 标识文档的层次结构 书写 wiki 文档时, 需要合理地规划层次结构, 增加文档的可读性 需要合理地使用表格, 列表等 html 元素, 增加文档的可读性 更多格式语法见 /WikiFormatting 当一个文档过长时, 可以考虑切分成几个文档, 或者当成一个项目 如何创建一个项目的 wiki 页面 一个项目通常有很多内容, 需要创建多个页面 先创建项目首页, 比如 /NewProject 再创建子页面, 比如: 设计文档: /NewProject/Design 如何部署: /NewProject/Deploy 每个子页面可以根据需要再创建子页面 编辑项目页面, 在底部加入下面的代码, 即可在项目页面上看到所有子页面: == 文章列表 == [[TitleIndex(NewProject)]]

工作模式(暂行) 4 天计划, 前紧后松 CoC, 主动 & 高效, 跨职能 的 技术团队 执行 敏捷开发 和 文档驱动 每日站会, 详见 45个习惯 第 8 章 代码集体所有制, 详见 45个习惯 第 8 章 CoC: Convention over Configuration 习惯优于配置 达成目标的方式有很多种, 可以灵活配置, 但遵从习惯可以降低沟通成本 版本控制: Git Java 包管理和部署: Maven 文档管理: wiki (Trac) 项目管理: Trello 习惯可以改, 只要好处 » 成本 主动&高效 主动提问, 站会匆匆而过, 没听明白的一定要问 主动沟通, 有问题超过 1h 搞不定, 就应该想想能找谁帮忙解决 主动通知, 邮件是广播 & 存档, 不能指望每个人都会看邮件, 但至少让 Ta 有地方去看 4 天做完 1 周的事, 剩下一天提高团队战斗力, 或者爱干嘛干嘛 一图抵万言, 确保大家说的 A 是同一个 A, 理解的 B 是同一个 B 跨职能 为了大家都能做一些爱做的事, 需要大家都做一些不爱做的事 每项工作都需要有至少 2 个人了解, 避免某件事情由于某个人不在就搞不定 技术团队 关注解决方案, 尽可能的解决问题 让 “这个很难”, “这个搞不定” 越来越少 领取 个人项目, 作为 bonus 借鉴 Scrum 敏捷开发框架 每周一个 Sprint, 按照大版本规划 Sprint 持续交付, 每个 Sprint 产出的结果对于最终用户都是有用的 每个 Sprint 需要分拆成最小 0.5D, 最大 2D 的任务 每天 10 ~ 20 分钟同步进度, 解决问题 使用 Trello 进行项目管理 文档驱动 任何 三个月后还有用的东西 都需要文档 文档需要回答的问题: 如果我完全不了解这个项目, 我想知道什么 怎么用: 如何部署/运行, 提供什么接口 怎么开发: 代码结构/核心算法/核心模块和逻辑(数据流图)

Git 入门资料 windows 客户端: http://git-scm.com/download/win Pro Git 中文版(书, 可能被墙): http://git-scm.com/book/zh Pro Git 中文下载版(pdf): http://ishare.iask.sina.com.cn/f/23292123.html 图解 Git (推荐阅读): http://my.oschina.net/xdev/blog/114383 windows 下 Git 的配置和使用 以下命令都在 Git Bash 中运行 生成公钥/私钥 ssh-keygen -t rsa 生成的密钥对的位置在 C:\Users\<user-name>\.ssh id_rsa 为私钥, id_rsa.pub 为公钥 配置 Git 的用户名和邮件 git config --global user.name <your-name> git config --global user.email <your-email> 进阶配置 编辑 <git-install-path>\etc\gitconfig 修改autocrlf = input, 确保提交的文本都是 utf8 编码 在文件末尾增加下面的代码, 使 Git GUI 能显示中文 [gui] encoding = utf-8 编辑 <git-install-path>\etc\git-completion.bash 在文件末尾增加下面的代码, 使 Git Bash 能显示中文 alias ls='ls --show-control-chars --color=auto' Git 使用规范 禁用中文文件名 所有文本文件使用 utf8 编码 所有文本文件使用 unix 换行 (\n), 而非 windows 换行 (\r\n) Git 分枝管理 master: 稳定可编译/测试通过的代码 test: 测试环境的代码, 通过测试后merge到master pri-xxx: 个人开发代码 (private), 由于可能需要到部署到服务器上, 因此允许 push 到 remote dev: 开发环境的代码 在 pri-xxx 上开发的代码, 可能需要 merge 到开发环境上验证 验证通过后, 禁止 直接把 dev merge 到 test, 而是应该从 pri-xxx merge 到 test 由于 dev 代码在多人 merge 后可能出问题, 所以定期会从 master 重开 dev 分枝 Git 注释规范 所有注释, 除了 merge 时系统自动生成的, 均应符合以下规范 格式为 <OPERATION>: description OPERATION 包括 ADD/MOD/DEL/FIX/MERGE/REFACTOR/CLEAN, 全部大写, 后面跟着冒号 description 需要是全英文, 包括标点 一次提交可以有多个 OPERATION, 但最好只有一个 多个 OPERATION 一行一个 OPERATION 何时使用 description应该写什么 ADD 增加功能/文件 增加了什么功能/文件(文件太多可以写目录) MOD 修改功能/文件 修改了什么功能/文件, 以及修改原因 DEL 删除功能/文件 删除了什么功能/文件, 以及删除原因 FIX 修复 bug bug 列表中有的, 可以只写 bug 号, 没有的需要说明 MERGE 手动合并 从哪里合并到哪里 (from x to y), 如何解决了冲突 REFACTOR 重构 重构了什么 CLEAN 清理 清理了什么

基本操作 创建版本库: git init 克隆版本库 git clone /path/to/repo git clone user@host:/path/to/repo 多版本库: git remote add <repo-name> <repo> 多版本库列表: git remote -v 更新版本库 git pull [repo-name] repo-name 默认为 origin git pull --rebase 可以避免无意义的 pull-merge, 使版本树尽可能是一条直线 git fetch [repo-name] - git pull does a git fetch followed by a git merge repo-name 默认为 origin 会把 repo-name 的更新都 fetch 到本地, 包括新分枝和新标签, 但不会建立本地分枝 提交到本地 stage: git add <file/dir> git commit -m "<comment>" 对于已经处于版本控制中的文件, 可以使用 git commit -am "<comment>" 略过 stage 有时需要构造空提交: git commit --allow-empty -m "EMPTY" 提交到远程 git push [repo-name] [branch] repo-name 默认为 origin, branch 默认为当前分枝 git push -u <repo-name> <branch> 设置 push/pull 时默认使用的 repo-name git push <repo-name> <branch>:<remote-branch> - 如果本地和远程分枝名字不同 反悔 revert stage: git reset HEAD <file> reset working: git checkout -- <file> restore(1+2): git checkout HEAD <file> checkout 上一个版本, 放在 stage/working 中: git checkout HEAD~ <file> 如果改动, add, 再改动, 使用 1. 不会恢复到第一次改动的结果; 使用 2. 才行! git reset <rev> [file] 没有 file 把 HEAD/branch 指向 rev 有 file 把 rev 版本的 file checkout 出来 如果 --hard, 那么 stage 和 working 都更新为 rev; 如果 --soft, 那么 stage 和 working 都不变(但 git status 会发现有文件 stage 了, 这是相对运动的结果); 如果 --mixed (默认), 那么只更新 stage (这时 git status 会发现 working 中有改动, 原因同上) rev 默认为 HEAD: 如果 --hard, 那么 stage 和 working 都更新为 HEAD (和 3. 效果一样); --soft 没意义; 如果 --mixed, 那么只更新 stage (就是 1. 咯~) 没有 file 时 --hard 类似于 checkout, 区别在于 reset <rev> 会移动 branch 指针, checkout <branch> 回不去, 而 checkout <rev> 再 checkout <branch> 可以回去 放弃所有本地改动(含本地提交): git reset --hard <repo-name>/<remote-branch> git checkout <rev> [file] 没有 file 会建立一个 detached HEAD (匿名分枝) - 最好别用! 有 file 把 rev 版本的 file checkout 出来 rev 默认为 -- 即 stage, 从 stage checkout 到 working 其它 rev 从 rev checkout 到 stage 再到 working git revert <rev>: 类似 svn 中的倒着 merge, 生成一个新版本 V+, 和 V-完全一样 - 仅用于 revert 一个很久以前的错误改动! 修改已经 push 到远程的提交 使用下面的方法修改已经 push 到远程的提交 git push <repo-name> +<branch>:<remote-branch> 修改上一个提交: git commit --amend 修改多个提交(交互式) git rebase -i <rev>, 编辑 rev 之后的提交, rev 默认为 repo-name/remote-branch 对于想合并到前一个的提交, 选择 fixup 对于想删除的提交, 直接删除对应的行 将上 N 个提交合并成一个 git reset --soft HEAD^(N-1) git commit --amend 分枝 建立分枝: git checkout -b <branch> 在当前 HEAD 上创建分枝并切换到新分枝 git checkout -b <branch> <repo-name>/<remote-branch> 跟踪远程分枝 切换分枝: git checkout <branch> 删除分枝: git branch -d <branch> 对于没有合并或提交到远程的分枝, 删除时会提示用 -D 强制删除 将分枝提交到远程(在远程建立新分枝): git push <repo-name> <branch> 提交到远程之后, 如果希望能够 pull 该分枝, 需要 git push -u 删除远程分枝: git push <repo-name> :<remote-branch> 删除已删除远程分枝的本地缓存: git remote prune origin 查看所有分枝: git branch -av git branch 不显示远程分枝 diff 分枝 diff: git diff <src-branch> <tgt-branch> (tgt 默认为当前分枝) 如果是和 master 比较, src-branch 应该是master 版本 diff: git diff <src-rev> <tgt-rev> (tgt 默认为当前版本) src-rev 应该是比 tgt-rev 更老的版本(祖先版本) git merge-base <src-branch> <tgt-branch> 可能可以得到你需要的 src-rev 其它 diff working 和 stage 的 diff: git diff stage 和 HEAD 的 diff: git diff --cached working 和 HEAD 的 diff: git diff HEAD 注意 上述 3 种方式都不会 diff 新文件(未处于版本控制中的文件) 合并 合并 branch 到当前分枝: git merge <branch> fetch 后用 git merge <repo-name>/<remote-branch> merge 如果 merge <branch>, 修改 branch, 再 merge, 只 merge 修改的部分 合并冲突时, 不 merge 而是指定某个版本: git checkout --ours/--theirs <file> “复制” 一次提交(比如某个分枝只有一次提交需要保留): git cherry-pick <rev> 停止 “复制”: git cherry-pick --abort 将当前分枝 rebase 到 tgt-branch: git rebase <tgt-branch> merge 与 rebase 的区别 merge 建立了一个新版本, 而 rebase 是分枝上有多少新版本, 就会建立多少新版本 rebase 后需要再做一次快速 merge, 才能使 tgt-branch 的指针正确(两者指针移动方式不同) 查看状态信息 git status git log git reflog: 查看 HEAD 指针的移动历史 git branch --merge: 查看哪些分枝已被合并到当前分枝 git branch --no-merged: 查看尚未合并的分枝 git remote show <repo-name>: 查看远程信息 暂存 git stash git stash pop git stash list git stash clear git stash apply stash@{x} git stash drop stash@{x} git stash branch <branch> 标签 git tag # 标签列表 git tag <tag> # 在当前版本上打标签 git show <tag> # 查看标签 git tag -d <tag> # 删除标签 git push <repo-name> <tag> # 提交标签 git push <repo-name> :<tag> # 删除远程标签 submodule @2015.04.13 git submodule add <remote-path> [<local-path>] # 添加 remote-path 为当前项目的 submodule git rm -r <local-path> # 如果有问题, 试试 git rm --cached <local-path> vim .gitmodules # 通常会在 git rm 时自动执行 git commit rm -rf .git/modules/<local-path> # 可能不必要 vim .git/config

引 版本控制工具：Git 代码 review 工具：ReviewBoard 代码 review 需要积极评估代码的设计和清晰程度，项目 owner 还要确保被review 代码的逻辑正确性，而不仅限于命名和格式 准备工作 用 ldap 账号登录 确保参与 review 的人都需要登录过，否则会找不到人 确保你要 review 的代码的 git 已经加入 reviewboard 确保你要 review 的代码基点已经 push 到 git 服务器 代码基点: git diff <src-rev> <tgt-rev> 中的 <src-rev> 提交一个 review 生成diff git diff <src-rev> <tgt-rev> > d1.diff 一般来说src是tgt的父节点 如何得到 <src-rev> 对于开分枝 / 开发 / merge 的工作模式而言 <src-rev> 就是你开分枝时分枝点的版本 可以用 git merge-base <src-branch> <tgt-branch> 得到 <src-rev> 比如你要从 work 分枝 merge 回 master，则执行 git merge-base master work 得到 <src-rev>，前提是你没有 merge 过 但如果你已经 merge 过，这样得到的 <src-rev> 是从最后一次 merge 的版本 对于在一个分枝上持续开发的工作模式 查看git log 找到需要的 <src-rev> 应该尽量在代码稳定时再 merge：勤开分枝，慎重 merge 应该尽量使用 amend，减少 commit，git log 才好找 访问 reviewboard，点击 New Review Request 选择 Repository，选择 diff 文件，点击 Create Review Request 点击 View Diff，查看上传结果是否和预期一致 填写 Summary / People / Description，注意 people 是 ldap 账号名，用 tab 补全，别按回车 确认提交，系统会发邮件给 people，通知他们来 review 更新一个 review 修改代码提交之后生成新 diff git diff <src-rev> <tgt-rev2> > d2.diff 注意 确保在一次 review 中，所有 diff 的 <src-rev> 都是同一个 访问 reviewboard，打开要更新的 review 只能更新自己提交的 review 点击 Update 下拉菜单中的 Update Diff，选择 diff 文件，点击 Upload 点击 View Diff，查看上传结果是否和预期一致 填写本次更新的内容，确认提交 review 别人的代码 点击邮件通知中的链接，登录 reviewboard 点击 View Diff，查看被修改的代码 点击有问题的行，填写有什么问题 继续 review，直到所有代码都 review 完毕 点击页面上方悬浮条中的 Edit Review，预览所有你填写的内容 如果没有问题，点击 Publish Review 如果需要修改，可以直接在预览页面上修改 如果需要增加，点击 Cancel，增加，再 Edit Review 如果代码较多，可以 review 一页提交一页 根据别人的 review 修改代码 别人提出的每个问题都会生成一个 issue 对照这些 issue 修改代码；如果 fix 了，就点 fixed；如果有异议，可以回复讨论；如果确认不需要改，就点 drop 修改完成后，提交代码，生成新的 diff 更新 review，继续，直到所有 issue 都 fixed 或 drop