翻译流程概述及PR说明.md

新翻译流程

Issue (旧)流程的简单复盘

使用 issue 来管理整套流程会带来以下痛点：

1. 每一次校对改动的不透明化：对于 issue 改动，如果校对人员直接对 issue 的 comment 进行修改，无法看到其修改历史和修改的具体内容及对比（改前片段&改后片段）；而如果在 comment 增加改动建议，则会对终稿中是否已经完成修改造成困扰，无法快速定位；
2. 当前 CMB 在文章定稿时无法快速定位到哪一篇是待发布文章 容易引起混乱；
3. 缺少翻译者和校对者的沟通与交流记录，对于翻译者翻译水平的提高不友好；
4. 上线后的文章修改流程困难且复杂，发布者无法再次重新进行快速挽救以及追责；

为了解决以上痛点，经校对成员讨论希望引入 git flow 流程，以项目开发中传统的代码 Review 流程，来管理博客翻译、校对、发布流程；

整体流程梳理

1. 领取流程：issue 作为文章池，与原先的抓取文章保持一致。
2. 临时分支定义：仅仅用来对 master 分支发起 PR，在整个流程结束后（Merge 进 master 分支）将临时分支删除。
3. 翻译完成后，对 repo 增加文件，发起 PR。然后进入校对流程，校对者对已经翻译文章的PR进行 comment 修改意见，由翻译者在 PR 中追加 commit 进行翻译修改。完成修改后确认修改无误对修改段落进行折叠。
4. 确认校对完成：当校对者完成校对工作后，在 comment 中回复 OK。每当一个 PR 获得两个 OK 后，方可由发布者 Merge。
5. 发布流程：当发布者需要当日更新文章，则从 PR 列表中对要发布的文章 PR 进行 merge，并进行主站发布工作。
6. 若上线文章出现问题，可从之前 merge 的 PR 中直接进行 Revert 操作，将该次翻译判为无效并对整个 flow 的经手人进行追责。若想再次上线该文章，需要重新发起 PR。

如何发起 Pull Request

Fork 工作流的好处

Fork 工作流与上述流程不一样，大家操作的并不是 GG 代码仓库。每个人都有一个属于自己的仓库，可以进行任意修改并且对 GG 仓库不会造成影响。Fork 工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送到他们自己的服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以接受任何开发者的提交，却不需要给他们中央仓库的权限。

Pull Request 操作说明

1. Fork 该仓库到自己的 GitHub 账号。得到一个自己的私有仓库可以任意修改并不会影响 GG 的仓库。
2. Clone 自己的的仓库到本地，例如：git clone [email protected]:BigNerdCoding/translation.git。
3. 添加 GG 仓库为另一个远程实现与 GG 仓库的同步，git remote add upstream https://github.com/SwiftGGTeam/translation.git 。
4. 在本地仓库新建分支完成自己的文章翻译并提交到自己的仓库。
5. 在自己的仓库中点击 New pull request 给 GG 仓库发 PR。
6. 如果需要根据校对意见进行修改，则修改后再走一遍上述 Commit -> PR 就行了。
7. 因为翻译是个协作流程，所以需要定期同步 GG 仓库的更改，此时依次运行：git fetch upstream、git checkout master 、git merge upstream/master 即可。最好是在自己准备翻译之前同步一次。

Q & A

Q：会不会带来和代码 merge 同样的问题，多分支 merge 造成的冲突？

A：不会。因为翻译流程 PR 只对 master 仓库进行 Add 文件操作，所以不会带来多人同事修改一个文件的情况。

Q：对于 Git 操作不熟悉的同学学习成本会不会比较大？

A：Git 属于分布式版本管理工具，我个人认为是每个程序员的必备技能之一。这里推荐一个教程 git-recipes。后期我会录制一个视频来讲解整个过程。

Q：翻译的文章放在哪里？如何命名？

A：翻译的文章统一放在网站对应的文件夹下，例如 appcode 站点的文章放在 appcode 文件夹下。文件命名方法：原文日期_原文标题.md，比如 20160726_simple-barcode-reader-app-swift.md。如果不确定文章放在哪里，群里问@BigNerdCoding

有不懂的问题，可以随时联系我(冬瓜)。