Git 合作开发教程
本文尚未完结，内容亟待补充、修正与排版，请谨慎阅读。
总算找到一个能写的主题了，实在是不容易。
一般来说，git的合作能够查到两种方式：
- 依赖于fork仓库，然后pull issue的。
- 依赖于多分支然后进行分支合并的
这方面倒是没有比较完善的（和我胃口的）教程，所以自己写一篇。
这篇教程不会介绍版本记录的基本用法，而是介绍如何用版本记录工具进行合作。
由于作者没有参加过任何实践中的大型项目正式开发，所以对feature、hot-fix啥的都不懂。这篇文章只是单纯地集中于——多人如何分配分支并且把各自的更新最终提交到master分支上。
基础知识：你几乎肯定会用到的操作
git revert 将当前分支的上上次提交作为一个新的修改提交
git reset 重置暂存区，但不修改文件（工作区）与HEAD指向
git reset –hard 改变HEAD指向，即撤销commit并且修改文件（工作区）
git stash 将当前工作区保存至一个临时存放点，同时恢复工作区到HEAD，等同于git stash save
git stash pop 弹出上一个指令保存的工作区修改
git checkout 转换到已存在的分支
git checkout -b 创建并转换到该分支
git branch 列出所有分支
git branch <分支名> 基于上次提交创建新分支
git merge —no-ff <分支名> 用于在主要版本更新分支合并dev分支，使用no-ff禁止fast forward，使得提交记录只有主要的合并记录。把这个参数去掉就是fast-forward或者三元合并了，但对于master和dev之间的关系来说，几乎肯定是fast-forward，详情请查询git的分支合并策略。
git rebase <分支名> 在个人分支合并来自其他人提交到主要分支上的信息，之所以不用merge，是为了防止出现极其混乱极其复杂的极其恐怖极其难以追溯的提交历史网状结构
git tag
git push –tags 推送tag到远程
fork & pull issue
本网站目前就是用这个方式多人合作编写的。适合于开源大型项目。
很遗憾的是，我实际上并不擅长于这种方式去合作。
checkout & merge
适合于同一工作团队进行合作开发。下面的内容局限于（我估计）最多十人的团队，如果是一个百人级别的团队，还请另寻高明了，比如多特性分支管理，具体了解hadoop的开发模式。
master分支，保持稳定，任何人不得直接提交，只能使用merge合并来自dev的分支。
dev分支，开发的主要分支，所以对master分支的改动必须得为经由dev分支merge而来。
具体来说，就是每人clone一个master分支，然后checkout一个dev分支，之后在dev分支开发。
任何人若想提交自己的更改到远程仓库，必须首先在本地dev分支commit，然后pull或者fetch + rebase，有冲突就解决冲突。本地合并完后再push到远程的dev分支。至于何时将远程的dev分支合并到master分支，则由管理人员决定。若决定发布一个大版本，则在master分支上打tag。
那可不可以直接每个人都使用单个master分支呢？当然是可以的，每个人clone后直接开发，然后commit，之后pull解决冲突，之后push。这样做也是能成的，因为本质上两台机器上的master分支也是不同分支，pull和push的过程中都会做merge，只要冲突都在本地解决好了，那么在远程仓库都可以顺利地merge。这种做法非常不正规，只建议在非常简单的情形下使用。
那么到底正式的做法与不正式的做法之间的区别在于哪里？在于你能够追溯到多么稳定的代码版本、各个分支上的代码稳定性、提交历史的清晰程度。