前几天翻译组使用了 GitHub 进行翻译管理。之前接触过 GitHub，仅限于接触而已，顶多 star、watch 过项目而已。
于是咨询了某位资深程序员。我只能说，如果你是他手下的小弟，你要是问了我这些问题，很可能就要被炒鱿鱼了。还好我是女的、又会卖萌，趁他心情不错，多蠢的问题都问，摊手~
话说，用 Git 查看译文和校对稿之间的不同，简直是太棒了！不同点一目了然，删除了什么、增加了什么，任何变动，都会标注出来。通过看不同， 能知道自己的翻译错误和常见毛病。瞬间路转粉，坚定了我一定要搞定 GitHub 的决心，以后常常使用 GitHub。
问题一
fork 之后创建 brach，和直接在原项目中创建 brach，有什么区别？
回答：
对原项目来说，有时候第三方没权限直接 push 或建立 branch。而 fork 之后就是自己的项目了，想做什么做什么。如果你可以直接在原项目中 push 或者创建 brach，说明管理员给你开放了权限。
问题二
什么是 push ？和 commit 有什么区别？
回答：
commit 是本地版本提交，push 提交到远程库中。
pull 是拉下更新，push 是把本地库更新提交到远程库里。
问题三
push 和 sync按钮 （GitHub Desktop 软件中的一个按钮）是一回事吗？
回答：
Sync 是 pull 加上 push。也就是说，用这个软件，无法实现单独的 push，必须同时进行 push 和 pull，也就是这里的 Sync。终端（Terminal）中可以用命令行进行 push（只 push，不 pull），强制提交。
问题四
创建分支（brach）和不创建分支有什么区别？或者说，创建分支有什么优势吗？
回答：
分支是按需求来产生的。
Example 1
你原来翻译的文章是这样的：
“XX**********XX********”
然后你忽然觉得把 “XX” 替换成 “YY” 更好，或者你想自己添加一些别的东西，你就可以新建一个分支，在这个分支上是独立，怎么改都行。最后觉得合适了，改完了，就可以把这个额外的分支合并到master 上。
Example 2
还有写测试代码的时候，不想改变原始的程序代码，但需要新添加一些测试部分的调试代码，就新建个分支，在分支上写测试，测试通过了， 直接切回去就可以了。
如果不创建分支，改完发现不合适，就得 rehead 到没改之前的节点，你改过的这部分工作就都被丢弃了，你下次又想改成"YY"了，就又得重来一遍。
多人合作的时候，你自己创建个分支，在自己的分支上提交不会影响别人，然后自己的工作差不多了， 再合并到主分支上，对大家都好。
问题五
那团队合作的时候，是不是一个人一个分支？有没有三四个人共用一个分支的情况？
回答：
多人共用分支很容易产生冲突，两个人同时修改一个文件的时候，问题也会比较多。
对分支而言，每天的新工作都可以创建一个分支，然后每天合并一次，或者需要的时候再合并。
问题六
分支只能合并到 master 上吗
回答：
不是，任何两个分支都可以合并在一起。各做各的，需要别人的部分，再去和那人合并。
问题七
clone 和 pull 有什么区别？
回答：
clone 相当于复制，把你的项目从远程库里复制到本地。之后本地库的每次改动，都需要 Sync（pull+push）来和远程库更新同步。也就是说，clone 一次就结束了，不需要多次 clone。但是 Sync 会操作很多次，每次想和远程库同步时，都需要点击 Sync。
再说几句
commit 强制备注，赞一个。
前端翻译项目示例
翻译流程图下图：
另外还有个事情提醒大家注意一下，尤其是已经工作了的同学，要记得改git里的user.name和user.email:
git config --local user.name='your Github name'
git config --local user.email='your Github email'
SwiftGG 翻译组项目示例
译者翻译流程：
首先 fork 这个仓库，请先从 master 分支上 git checkout -b translate 一个新的 translate 分支来翻译文章。
在仓库的主目录中，新建自己负责翻译的 Blog 文件夹。以后关于该 Blog 所有译文都放置在对应的文件夹中。
翻译完成后去主仓库开 issue，标题为『翻译文章中文标题』，内容粘贴上相应的 commit 链接，将右边的 Labels 标签修改为『待校对』，Assignees 选择和自己组队校对的小伙伴。
校对的小伙伴校对完成后，根据其修改意见（comment 形式）对译文进行修正，将 issue label 改为『待定稿』。
发送 Pull Request，注意：发 PR 的时候请注意检查，一个 PR 只能有一篇文章，切勿两篇或多篇 合并到一个 PR。
校对者流程：
在接收到译者分配的校对任务后，进入主仓库相关 issue，将左侧 label 改为『校对中』。
进入译者的 commit 链接，通过添加 comment 的方式对译者内容进行校对。
校对完成后，将 issue label 改为『校对完成』，并把 Assignees 重新指定给译者。
实战经验文集里记录了我平时开发中遇到的一些经验，记录是希望下次再遇到类似的问题，能够迅速解决。不要重复在同一个事情上花时间搜索解决方法。
