github操作整理

Github是一个分布式版本管理团队合作系统，https://github.com/

分布式版本管理系统的几大基本要素：仓库、爬取、提交、发布、合并

不管是github或者是svn等，都是遵从这几个流程来办事的，只是叫法不一样，其他的操作都是从这些环节中衍生出来的。

仓库（repository）：通常作为一个项目的根或者某些资料存储目录的根，通常存放项目的主线版本及快照，也就是所谓的基线。

爬取 （fetch）：就是从仓库中获取一份副本，从而在本地或自身的域中进行操作，不影响基线版本。

提交 （commit）：将所做的修改应用到版本。如果是在线提交，那么会直接更新基线。如果在本地，那么提交操作通常是更新本地副本。

发布（push）：将副本版本更新到基线版本。

合并（merge）：伴随着发布而触发的操作，如果只是一人发布，则直接跟基线合并，如果多人发布，则衍生出一系列程序{

分支（branch）：每个人都在各自独立的副本作业，每个副本作为一个分支。如果分支满足某些条件，也会成为子级的基线。

合并{

    直接合并（merge commit）：无关提交顺序的先后，取决于基线管理员的选择，将每个人被认可的副本合并到基线。

    装箱合并（squash and commit）:这个有点复杂，不同的系统实现机制有可能不同。一般来说，组员每次提交就会产生一次记录，对应在发布后的基线就会残留许多意义不大的快照，squash 将这些提交压缩为一次完整发布，基线版本保留最后一次有意义的提交记录。//有些系统是用指针来操作提交记录而非完整提交，如github，如果快进提交，可能会导致进度丢失，而quash and commit就可以避免这种情况。

    基线重置（rebase and commit）：这种方式主要针对多人合并基线的进程树，试想一下汉诺塔，有三根柱子，柱子上的饼是依次排列好的了，一串饼就相当于一个分支，而我们要将这些饼全部套在其中一根柱子上，这就好比直接合并，由于移动顺序有先后，导致柱子上的饼顺序混乱，所以rebase 直接将饼一整串的移动，中间不穿插其他串，从而保证了每一串原有的连续性。多分支的情况下，rebase可以让基线的快照可读性更好。

    }

}

以上提到的这些都是常用的版本管理操作，github的网页UI提供就是这样操作办法，如果是桌面程序或者第三方、命令行方式使用，还有更多细化的操作以满足各种需要，这里就不细说。

在github，fetch是fork，你必须先fork别人的库，才能执行后续的操作。另外，将你的东西提交到别人的库，就是push，github中叫做pull request。

不管是git还是svn，多人工作下开始写代码前一定要先检出，以便保证其他人的代码是最新的。划分好工作模块，fork别人的项目，如果新增功能，则不能修改原来的内容，否则owner合并的时候查看冲突会生气，如果是发现bug并提交修复，则要注明bug用例和修改说明。

网页版的github性能有限，通常使用桌面客户端使用。我个人感觉这样搭配比较好：

• 社交操作如star、概览等，用网页
• 工作环境用IDE+git插件就很方便，能满足基本的操作。
• 协作讨论使用Gitkraken，因为有很友好的flow，只是文件状态过于体验化不够实用。

以上的东西理解了，git的使用就很快上手了。