新翻译流程

Issue (旧)流程的简单复盘

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

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

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

整体流程梳理

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

如何发起 Pull Request

Fork 工作流的好处

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

Pull Request 操作说明

Fork 该仓库到自己的 GitHub 账号。得到一个自己的私有仓库可以任意修改并不会影响 GG 的仓库。
Clone 自己的的仓库到本地，例如：git clone git@github.com:BigNerdCoding/translation.git。
添加 GG 仓库为另一个远程实现与 GG 仓库的同步，git remote add upstream https://github.com/SwiftGGTeam/translation.git 。
在本地仓库新建分支完成自己的文章翻译并提交到自己的仓库。
在自己的仓库中点击 New pull request 给 GG 仓库发 PR。
如果需要根据校对意见进行修改，则修改后再走一遍上述 Commit -> PR 就行了。
因为翻译是个协作流程，所以需要定期同步 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

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

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