回滚、还原、重置和变基
- 关键词:Git For Teams – 读书笔记
Part2 在工作流中使用命令
1 准备评审
完成一次同行评审是非常耗时的,然而,它的好处的巨大的。
初级程序员可以接触到代码库中更多的代码,而不只是他们正在进行的那部分工作。资深开发者有更多的机会来质询代码库中可能影响到未来工作的决策。
通过采用及时的同行评审过程,我们节省了每个冲刺最后的人工质量保证测试所需的时间。
- 评审类型
- 设计评判
- 技术架构评审(确保数据模型已经完成,且易于对接构建的所有部分,可能有未来的功能)
- 自动化自检(编码标准,而不是浪费时间执行人工检查)
- 基于工单的同行代码评审
- 质量保证/用户验收测试
2 评审者类型
同行评审、自动化的把门人、共识的牧羊人、仁慈的独裁者
初级评审者和资深评审者的收益 | 初级评审者 | 资深评审者 |
---|---|---|
初级评审者 | 寻找bug;遵循标准 | 学会阅读优秀的代码;建议如何精简;接触到完整的代码库 |
资深评审者 | 建议新的技术;改善架构 | 改善架构;跨功能团队(接触更多的代码) |
3 用于代码评审的软件
下面的软件包专注于代码评审和签发,它们适用于超大型软件项目的代码评审:Gerrit和Review Board
自动化测试工具:Drupal、PullReview和bitHound
4 评审issue
5 应用提议更改
5.1 共享仓库设置
git fetch(如果是一个共享仓库中工作)
git fetch origin(如果是多个远程,就需要显式指定你想要更新的远程的分支origin)
如果你使用自动化构建环境,那么或许需要显式拉取你想要评审的分支。使用你的远程名称替换origin,并用你想要评审的分支名称替换xxx-broken-link。
git fetch origin xxx-broken-link:xxx-broken-link
xxx-broken-link:xxx-broken-link是一个引用规格,将远程分支的名称映射到一个本地分支的名称([remote_branch_name]:[local_branch_name]),根据约定,分支名称要相同。
5.2 派生仓库的设置
有两种方法可以处理派生仓库的场景。第一种是克隆一份包含提议分支的新的远程仓库副本。第二种方法是在我们自己的本地仓库中添加一个新的远程仓库,并将更改拉取到我们自己的仓库中的一个新的分支。
如果是第一种方法:
git clone https:…
cd project
如果你在评审Donna的工作,而她的仓库位于https:。。。,则:
git add remote donna https:…
get fetch donna
5.3 签出提议分支
git branch –all(列出仓库中的所有分支)
git checkout –track origin/…
6 评审提议的更改
git log master..(查看分支的提交历史)
git log –oneline –graph(使用图形化的log命令来验证当前的分支)
git diff master(展示了你的仓库中两个节点之间的差异,这些对象可以是提交对象、分支顶端和暂存区)
如果你想要看到补丁中更改的更简略的对比,可以考虑只列出文件,然后每次查看一个更改的文件:
git diff master –stat
git diff master filename
-
使用gitk工具,会启动一个图形化工具
-
Kaleidoscope应用,可以找出图片中的差异
7 准备你的反馈
代码错误、代码没有遵守最佳实践、代码的写法与你的预期不符。
8 提交你的评估结果
如果是前两种,那么将它修复。减少开发者和评审者之间交流的次数。
如果是第三种情况,则立即停止。找出原作者,进行对话。
git add –all
git commit -m “Correcting
identified in peer review"
假设你将这个分支设为跟踪分支:
git push
9 完成评审
git checkout master
git pull –rebase=preserve origin master
git merge –no–ff …
git push
git branch –delete …
git push origin –delete …