mirror of
https://github.com/oldratlee/translations.git
synced 2026-05-11 10:30:36 +08:00
emojify
This commit is contained in:
Jerry Lee
@@ -2,8 +2,7 @@
|
||||
译文发在[博乐在线](http://www.jobbole.com/)： [http://blog.jobbole.com/76550/](http://blog.jobbole.com/76843/)，2014-09-14
|
||||
PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atlassian.com/git/workflows)，`atlassian`改地址后换了文章标题，译文保留使用原标题。
|
||||
|
||||
:apple: 译序
|
||||
-----------------
|
||||
## 🍎 译序
|
||||
|
||||
关于`Git`工作流主题，也许这是目前最全面最深入的说明。这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，体系地讲解了各种工作流的应用。
|
||||
如果你`Git`用的还不多，可以从前面的讲的工作流开始操练。操作过程去感受指南的讲解：解决什么问题、如何解决问题，这样理解就深了，也方便活用。
|
||||
@@ -29,7 +28,7 @@ PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atl
|
||||
|
||||
----------------
|
||||
|
||||
- :see_no_evil: [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 :clap:
|
||||
- 🙈 [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 👏
|
||||
- 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new)
|
||||
- 指正，[`Fork`后提通过`Pull Request`贡献修改](https://github.com/oldratlee/translations/fork)
|
||||
- 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起交流学习讨论！
|
||||
@@ -39,13 +38,13 @@ PS：原文的老链接和标题是[Git Workflows and Tutorials](https://www.atl
|
||||
`Git`工作流指南
|
||||
======================
|
||||
|
||||
:point_right: 工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种`Git`工作流让大家可以上手使用。
|
||||
👉 工作流有各式各样的用法，但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队中最常用的几种`Git`工作流让大家可以上手使用。
|
||||
|
||||
在阅读的过程中请记住，本文中的几种工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后，你可以从不同的工作流中挑选或揉合出一个满足你自己需求的工作流。
|
||||
|
||||
|
||||
|
||||
:beer: 概述
|
||||
🍺 概述
|
||||
---------------------
|
||||
|
||||
### 集中式工作流
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
`Pull Requests`是`Bitbucket`上方便开发者之间协作的功能。
|
||||
提供了一个用户友好的`Web`界面，在集成提交的变更到正式项目前可以对变更进行讨论。
|
||||
|
||||
|
||||
|
||||
|
||||
开发者向团队成员通知功能开发已经完成，`Pull Requests`是最简单的用法。
|
||||
开发者完成功能开发后，通过`Bitbucket`账号发起一个`Pull Request`。
|
||||
@@ -29,7 +29,7 @@
|
||||
如果变更有任何问题，团队成员反馈在`Pull Request`中，甚至`push`新的提交微调功能。
|
||||
所有的这些活动都直接跟踪在`Pull Request`中。
|
||||
|
||||
|
||||
|
||||
|
||||
相比其它的协作模型，这种分享提交的形式有助于打造一个更流畅的工作流。
|
||||
`SVN`和`Git`都能通过一个简单的脚本收到通知邮件；但是，讨论变更时，开发者通常只能去回复邮件。
|
||||
@@ -42,12 +42,12 @@
|
||||
来`pull`你仓库中一个分支到他的仓库中。这意味着你要提供4个信息以发起`Pull Request`：
|
||||
源仓库、源分支、目的仓库、目的分支。
|
||||
|
||||
|
||||
|
||||
|
||||
这几值多数`Bitbucket`都会设置上合适的缺省值。但取决你用的协作工作流，你的团队可能会要指定不同的值。
|
||||
上图显示了一个`Pull Request`请求合并一个功能分支到正式的`master`分支上，但可以有多种不同的`Pull Request`用法。
|
||||
|
||||
:beer: 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
`Pull Request`可以和[功能分支工作流](workflow-feature-branch.md)、[`Gitflow`工作流](workflow-gitflow.md)或[`Forking`工作流](workflow-forking.md)一起使用。
|
||||
@@ -67,7 +67,7 @@
|
||||
功能分支工作流用一个共享的`Bitbucket`仓库来管理协作，开发者在专门的分支上开发功能。
|
||||
但不是立即合并到`master`分支上，而是在合并到主代码库之前开发者应该开一个`Pull Request`发起功能的讨论。
|
||||
|
||||
|
||||
|
||||
|
||||
功能分支工作流只有一个公开的仓库，所以`Pull Request`的目的仓库和源仓库总是同一个。
|
||||
通常开发者会指定他的功能分支作为源分支，`master`分支作为目的分支。
|
||||
@@ -85,7 +85,7 @@
|
||||
在`Gitflow`工作流中使用`Pull Request`让开发者在发布分支或是维护分支上工作时，
|
||||
可以有个方便的地方对关于发布分支或是维护分支的问题进行交流。
|
||||
|
||||
|
||||
|
||||
|
||||
`Gitflow`工作流中`Pull Request`的使用过程和上一节中完全一致：
|
||||
当一个功能、发布或是热修复分支需要`Review`时，开发者简单发起一个`Pull Request`，
|
||||
@@ -102,7 +102,7 @@
|
||||
在这个工作流，`Pull Request`的通知功能非常有用，
|
||||
因为项目维护者不可能知道其它开发者在他们自己的仓库添加了提交。
|
||||
|
||||
|
||||
|
||||
|
||||
由于各个开发有自己的公开仓库，`Pull Request`的源仓库和目标仓库不是同一个。
|
||||
源仓库是开发者的公开仓库，源分支是包含了修改的分支。
|
||||
@@ -113,13 +113,13 @@
|
||||
用团队成员的`Bitbucket`仓库作为目标，而不是正式项目的仓库。
|
||||
然后使用相同的功能分支作为源和目标分支。
|
||||
|
||||
|
||||
|
||||
|
||||
2个开发者之间可以在`Pull Request`中讨论和开发功能。
|
||||
完成开发后，他们可以发起另一个`Pull Request`，请求合并功能到正式的`master`分支。
|
||||
在`Forking`工作流中，这样的灵活性让`Pull Request`成为一个强有力的协作工具。
|
||||
|
||||
:beer: 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
下面的示例演示了`Pull Request`如何在在`Forking`工作流中使用。
|
||||
@@ -129,18 +129,18 @@
|
||||
|
||||
### 小红`fork`正式项目
|
||||
|
||||
|
||||
|
||||
|
||||
小红先要`fork`小明的`Bitbucket`仓库，开始项目的开发。她登陆`Bitbucket`，浏览到小明的仓库页面，
|
||||
点`Fork`按钮。
|
||||
|
||||
|
||||
|
||||
|
||||
然后为`fork`出来的仓库填写名字和描述，这样小红就有了服务端的项目拷贝了。
|
||||
|
||||
### 小红克隆她的`Bitbucket`仓库
|
||||
|
||||
|
||||
|
||||
|
||||
下一步，小红克隆自己刚才`fork`出来的`Bitbucket`仓库，以在本机上准备出工作拷贝。命令如下：
|
||||
|
||||
@@ -152,7 +152,7 @@ git clone https://user@bitbucket.org/user/repo.git
|
||||
|
||||
### 小红开发新功能
|
||||
|
||||
|
||||
|
||||
|
||||
在开始改代码前，小红要为新功能先新建一个新分支。她会用这个分支作为`Pull Request`的源分支。
|
||||
|
||||
@@ -167,7 +167,7 @@ git commit -a -m "Add first draft of some feature"
|
||||
|
||||
### 小红`push`功能到她的`Bitbucket`仓库中
|
||||
|
||||
|
||||
|
||||
|
||||
小红完成了功能后，`push`功能到她自己的`Bitbucket`仓库中（不是正式仓库），用下面简单的命令：
|
||||
|
||||
@@ -179,7 +179,7 @@ git push origin some-branch
|
||||
|
||||
### 小红发起`Pull Request`
|
||||
|
||||
|
||||
|
||||
|
||||
`Bitbucket`上有了她的功能分支后，小红可以用她的`Bitbucket`账号浏览到她的`fork`出来的仓库页面，
|
||||
点右上角的【`Pull Request`】按钮，发起一个`Pull Request`。
|
||||
@@ -189,13 +189,13 @@ git push origin some-branch
|
||||
而目标分支是`master`分支。另外，小红需要提供`Pull Request`的标题和描述信息。
|
||||
如果需要小明以外的人审核批准代码，她可以把这些人填在【Reviewers】文本框中。
|
||||
|
||||
|
||||
|
||||
|
||||
创建好了`Pull Request`，通知会通过`Bitbucket`系统消息或邮件（可选）发给小明。
|
||||
|
||||
### 小明review `Pull Request`
|
||||
|
||||
|
||||
|
||||
|
||||
在小明的`Bitbucket`仓库页面的【`Pull Request`】Tab可以看到所有人发起的`Pull Request`。
|
||||
点击小红的`Pull Request`会显示出`Pull Request`的描述、功能的提交历史和每个变更的差异（`diff`）。
|
||||
@@ -205,7 +205,7 @@ git push origin some-branch
|
||||
但如果像这个示例中一样小明发现了在小红的代码中的一个小`Bug`，要小红在合并前修复。
|
||||
小明可以在整个`Pull Request`上加上评注，或是选择历史中的某个提交加上评注。
|
||||
|
||||
|
||||
|
||||
|
||||
### 小红补加提交
|
||||
|
||||
@@ -219,7 +219,7 @@ git push origin some-branch
|
||||
最终，小明接受变更，合并功能分支到`master`分支，并关闭`Pull Request`。
|
||||
至此，功能集成到项目中，其它的项目开发者可以用标准的`git pull`命令`pull`这些变更到自己的本地仓库中。
|
||||
|
||||
:beer: 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
到了这里，你应该有了所有需要的工具来集成`Pull Request`到你自己的工作流。
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
其次，`Git`提供了强壮的分支和合并模型。不像`SVN`，`Git`的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。
|
||||
|
||||
:beer: 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
像`Subversion`一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`叫做`master`，所有修改提交到这个分支上。本工作流只用到`master`这一个分支。
|
||||
@@ -48,7 +48,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`操作，重来一次（或者让别人来帮助解决）。
|
||||
|
||||
:beer: 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红，看他们是如何开发自己的功能并提交到中央仓库上的。
|
||||
@@ -230,7 +230,7 @@ git push
|
||||
# 原因同上
|
||||
```
|
||||
|
||||
:beer: 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
如你所见，仅使用几个`Git`命令我们就可以模拟出传统`Subversion`开发环境。对于要从`SVN`迁移过来的团队来说这太好了，但没有发挥出`Git`分布式本质的优势。
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
另外，如果你在功能开发中有问题卡住了，可以开一个`pull requests`来向同学们征求建议。
|
||||
这些做法的重点就是，`pull requests`让团队成员之间互相评论工作变成非常方便！
|
||||
|
||||
:beer: 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
功能分支工作流仍然用中央仓库，并且`master`分支还是代表了正式项目的历史。
|
||||
@@ -53,7 +53,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)。
|
||||
|
||||
:beer: 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
下面的示例演示了如何把`Pull Requests`作为`Code Review`的方式，但注意`Pull Requests`可以用于很多其它的目的。
|
||||
@@ -146,7 +146,7 @@ git push
|
||||
这个过程常常会生成一个合并提交。有些开发者喜欢有合并提交，因为它像一个新功能和原来代码基线的连通符。
|
||||
但如果你偏爱线性的提交历史，可以在执行合并时`rebase`新功能到`master`分支的顶部，这样生成一个快进（`fast-forward`）的合并。
|
||||
|
||||
【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:）
|
||||
【译注】生成一个快进的合并的命令行：（感觉步骤有些多:sweat:，欢迎给出更简捷的做法:two_hearts:）
|
||||
|
||||
```bash
|
||||
git checkout marys-feature
|
||||
@@ -167,7 +167,7 @@ git push
|
||||
|
||||
通过隔离功能到独立的分支上，每个人都可以自主的工作，当然必要的时候在开发者之间分享变更还是比较繁琐的。
|
||||
|
||||
:beer: 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
到了这里，但愿你发现了功能分支可以很直接地在[集中式工作流](workflow-centralized.md)的仅有的`master`分支上完成多功能的开发。
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。
|
||||
也让这个工作流成为开源项目的理想工作流。
|
||||
|
||||
:beer: 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
和其它的`Git`工作流一样，`Forking`工作流要先有一个公开的正式仓库存储在服务器上。
|
||||
@@ -58,7 +58,7 @@
|
||||
各个开发者应该用分支隔离各个功能，就像在[功能分支工作流](workflow-feature-branch.md)和[`Gitflow`工作流](workflow-gitflow.md)一样。
|
||||
唯一的区别是这些分支被共享了。在`Forking`工作流中这些分支会被`pull`到另一个开发者的本地仓库中，而在功能分支工作流和`Gitflow`工作流中是直接被`push`到正式仓库中。
|
||||
|
||||
:beer: 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
### 项目维护者初始化正式仓库
|
||||
@@ -197,7 +197,7 @@ git push origin master
|
||||
git pull upstream master
|
||||
```
|
||||
|
||||
:beer: 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
如果你之前是使用`SVN`，`Forking`工作流可能看起来像是一个激进的范式转换（**_paradigm shift_**）。
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。
|
||||
当然你可以用上功能分支工作流所有的好处：`Pull Requests`、隔离实验性开发和更高效的协作。
|
||||
|
||||
:beer: 工作方式
|
||||
🍺 工作方式
|
||||
---------------------
|
||||
|
||||
`Gitflow`工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并`push`分支到要中央仓库中。
|
||||
@@ -80,7 +80,7 @@
|
||||
为`Bug`修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
|
||||
你可以把维护分支想成是一个直接在`master`分支上处理的临时发布。
|
||||
|
||||
:beer: 示例
|
||||
🍺 示例
|
||||
---------------------
|
||||
|
||||
下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。
|
||||
@@ -217,7 +217,7 @@ git push
|
||||
git branch -d issue-#001
|
||||
```
|
||||
|
||||
:beer: 下一站
|
||||
🍺 下一站
|
||||
-----------------
|
||||
|
||||
到了这里，但愿你对[集中式工作流](workflow-centralized.md)、[功能分支工作流](workflow-feature-branch.md)和`Gitflow`工作流已经感觉很舒适了。
|
||||
|
||||
Reference in New Issue
Block a user