mirror of
https://github.com/oldratlee/translations.git
synced 2026-02-02 17:59:34 +08:00
remove redundant space
This commit is contained in:
Jerry Lee
@@ -1,7 +1,7 @@
|
||||
欢迎贡献
|
||||
====================
|
||||
|
||||
- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏
|
||||
- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏
|
||||
- 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new)
|
||||
- 指正，[`Fork`后提通过`Pull Requst`贡献修改](https://github.com/oldratlee/translations/fork)
|
||||
- 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起学习交流讨论！
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
|
||||
其次，`Git`提供了强壮的分支和合并模型。不像`SVN`，`Git`的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。
|
||||
|
||||
🍺 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
像`Subversion`一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`叫做`master`，所有修改提交到这个分支上。本工作流只用到`master`这一个分支。
|
||||
@@ -54,7 +54,7 @@
|
||||
|
||||
如果本地修改和上游提交有冲突，`Git`会暂停`rebase`过程，给你手动解决冲突的机会。`Git`解决合并冲突，用和生成提交一样的[`git status`](https://www.atlassian.com/git/tutorials/inspecting-a-repository#git-status)和[`git add`](https://www.atlassian.com/git/tutorials/saving-changes#git-add)命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，`Git`可以很简单中止整个`rebase`操作，重来一次（或者让别人来帮助解决）。
|
||||
|
||||
🍺 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。
|
||||
@@ -210,7 +210,7 @@ CONFLICT (content): Merge conflict in <some-file>
|
||||
接着小红编辑这些文件。修改完成后，用老套路暂存这些文件，并让[`git rebase`](https://www.atlassian.com/git/tutorials/rewriting-history#git-rebase)完成剩下的事：
|
||||
|
||||
```bash
|
||||
git add <some-file>
|
||||
git add <some-file>
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
@@ -236,7 +236,7 @@ git push
|
||||
# 原因同上
|
||||
```
|
||||
|
||||
🍺 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
如你所见，仅使用几个`Git`命令我们就可以模拟出传统`Subversion`开发环境。对于要从`SVN`迁移过来的团队来说这太好了，但没有发挥出`Git`分布式本质的优势。
|
||||
|
||||
@@ -33,7 +33,7 @@
|
||||
另外，如果你在功能开发中有问题卡住了，可以开一个`pull requests`来向同学们征求建议。
|
||||
这些做法的重点就是，`pull requests`让团队成员之间互相评论工作变成非常方便！
|
||||
|
||||
🍺 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
功能分支工作流仍然用中央仓库，并且`master`分支还是代表了正式项目的历史。
|
||||
@@ -60,7 +60,7 @@
|
||||
|
||||
仓库管理的产品解决方案像[`Bitbucket`](http://bitbucket.org/)或[`Stash`](http://www.atlassian.com/stash)，可以良好地支持`Pull Requests`。可以看看`Stash`的[`Pull Requests`文档](https://confluence.atlassian.com/display/STASH/Using+pull+requests+in+Stash)。
|
||||
|
||||
🍺 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
下面的示例演示了如何把`Pull Requests`作为`Code Review`的方式，但注意`Pull Requests`可以用于很多其它的目的。
|
||||
@@ -153,7 +153,7 @@ git push
|
||||
这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。
|
||||
但如果你偏爱线性的提交历史，可以在执行合并时`rebase`新功能到`master`分支的顶部，这样生成一个快进（`fast-forward`）的合并。
|
||||
|
||||
【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:）
|
||||
【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:）
|
||||
|
||||
```bash
|
||||
git checkout marys-feature
|
||||
@@ -174,7 +174,7 @@ git push
|
||||
|
||||
通过隔离功能到独立的分支上，每个人都可以自主的工作，当然必要的时候在开发者之间分享变更还是比较繁琐的。
|
||||
|
||||
🍺 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
到了这里，但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。
|
||||
也让这个工作流成为开源项目的理想工作流。
|
||||
|
||||
🍺 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
和其它的`Git`工作流一样，`Forking`工作流要先有一个公开的正式仓库存储在服务器上。
|
||||
@@ -65,7 +65,7 @@
|
||||
各个开发者应该用分支隔离各个功能，就像在[功能分支工作流](workflow-feature-branch.md)和[`Gitflow`工作流](workflow-gitflow.md)一样。
|
||||
唯一的区别是这些分支被共享了。在`Forking`工作流中这些分支会被`pull`到另一个开发者的本地仓库中，而在功能分支工作流和`Gitflow`工作流中是直接被`push`到正式仓库中。
|
||||
|
||||
🍺 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
### 项目维护者初始化正式仓库
|
||||
@@ -204,7 +204,7 @@ git push origin master
|
||||
git pull upstream master
|
||||
```
|
||||
|
||||
🍺 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
如果你之前是使用`SVN`，`Forking`工作流可能看起来像是一个激进的范式转换（**_paradigm shift_**）。
|
||||
|
||||
@@ -32,7 +32,7 @@
|
||||
除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。
|
||||
当然你可以用上功能分支工作流所有的好处：`Pull Requests`、隔离实验性开发和更高效的协作。
|
||||
|
||||
🍺 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
`Gitflow`工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并`push`分支到要中央仓库中。
|
||||
@@ -87,7 +87,7 @@
|
||||
为`Bug`修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
|
||||
你可以把维护分支想成是一个直接在`master`分支上处理的临时发布。
|
||||
|
||||
🍺 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。
|
||||
@@ -224,7 +224,7 @@ git push
|
||||
git branch -d issue-#001
|
||||
```
|
||||
|
||||
🍺 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
到了这里，但愿你对[集中式工作流](workflow-centralized.md)、[功能分支工作流](workflow-feature-branch.md)和`Gitflow`工作流已经感觉很舒适了。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
基于开源中国社区的译文稿： [日志：每个软件工程师都应该知道的有关实时数据的统一概念](http://www.oschina.net/translate/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)
|
||||
译文发在[伯乐在线](http://blog.jobbole.com/)：[The Log：每个程序员都应该知道有关实时数据的统一抽象](http://blog.jobbole.com/89674/)， 2015-08-21
|
||||
|
||||
## 🍎 译序
|
||||
## 🍎 译序
|
||||
|
||||
这篇文章是`LinkedIn`的`Kreps`发表的一篇博文，虽然很长，但被称为[程序员史诗般必读文章](http://bryanpendleton.blogspot.hk/2014/01/the-log-epic-software-engineering.html)。
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
但作为一篇 **_经典_** 文章，还是值得去完整地研读和理解：
|
||||
|
||||
1. 原文可以作为大数据/分布式系统领域一份导论式的资料。
|
||||
1. 原文可以作为大数据/分布式系统领域一份导论式的资料。
|
||||
作者对整个领域的理解和实战精深广博，抓出并梳理了这个领域的核心：日志。
|
||||
1. 原文作为一手资料，有完整的分析过程，能够深入和核对自己的理解。
|
||||
1. 解读和摘要不能替代自己理解。
|
||||
|
||||
@@ -83,7 +83,7 @@
|
||||
|
||||
对于这一领域，我将持续关注，如果您知道一些我遗漏的内容，请您告知。
|
||||
|
||||
最后我留给你的信息是这个： 😸
|
||||
最后我留给你的信息是这个： 😸
|
||||
[](https://www.youtube.com/watch?v=2C7mNr5WMjA)
|
||||
|
||||
-----------------
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
原文链接：[推荐学习LISP的书籍](http://blog.sina.com.cn/s/blog_72d43af30100pg5t.html) - [图谱实验室](http://blog.sina.com.cn/tupulab)，2011-02-01 21:10:14
|
||||
原文链接：[推荐学习LISP的书籍](http://blog.sina.com.cn/s/blog_72d43af30100pg5t.html) - [图谱实验室](http://blog.sina.com.cn/tupulab)，2011-02-01 21:10:14
|
||||
|
||||
<img src="lisp.png" width="192" hspace="10px" align="right" >
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ ANSI Common Lisp
|
||||
On Lisp: Advanced Techniques for Common Lisp
|
||||
-------------------------------------
|
||||
|
||||
*Graham*, Prentice Hall, 1994, ISBN 0-13-030552-9
|
||||
*Graham*, Prentice Hall, 1994, ISBN 0-13-030552-9
|
||||
|
||||
这本书已经成为了宏技术的权威参考。
|
||||
|
||||
|
||||
@@ -21,9 +21,9 @@
|
||||
`stubs`只检查的是状态（`state`），而`mocks`检查了行为（`behavior`）。在测试中使用`mock`，不仅检查你测试和其依赖之间和状态，而且还有行为。
|
||||
|
||||
> 原文如下：
|
||||
>
|
||||
>
|
||||
> Stubs vs. Mocks
|
||||
>
|
||||
>
|
||||
> In the article “Mocks Aren’t Stubs,” (<http://martinfowler.com/articles/mocksArentStubs.html>),
|
||||
> Martin Fowler discusses the difference between stubs and mocks. A stub stands in for a real object.
|
||||
> It simply reciprocates the coached expected response when called by the code being tested.
|
||||
|
||||
@@ -84,7 +84,7 @@ issues = "!f() { : git log ; echo 'Printing issue keys'; git log --oneline $@ |
|
||||
>
|
||||
> 当从子目录运行时，命令输出的路径通常相对于当前目录。这个选项强制输出的路径是相对项目的顶级目录。
|
||||
|
||||
非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径，拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。如果你也觉得有用，只要简单运行：
|
||||
非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径，拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。如果你也觉得有用，只要简单运行：
|
||||
|
||||
```bash
|
||||
$ git config --global grep.fullname true
|
||||
@@ -115,7 +115,7 @@ $ git replace --edit master
|
||||
$ git replace --edit master:jira-components/pom.xml
|
||||
```
|
||||
|
||||
应该这么做？基本上不会 😄 大部分情况应该用`git rebase`重写对象，这样会正确的重写提交的`SHA`，保证历史是健全的（`sane history`）。
|
||||
应该这么做？基本上不会 😄 大部分情况应该用`git rebase`重写对象，这样会正确的重写提交的`SHA`，保证历史是健全的（`sane history`）。
|
||||
|
||||
> `git replace`会读取`--graft`选项，可以编辑父提交。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user