本文参考：
Git Reference
Git 分支模型
工欲善其事必先利其器，本文目的是列出常用的git命令，并简单回忆一下Git分支管理模型：
- 分支管理
- 查看
- 创建分支
- 提交
- 合并多个commit
- 选择合并某个commit
- 解决冲突
- 文本文件冲突
- zip文件冲突
- 版本回退
- 回退到某个commit
- 回退到某个操作
- 查看日志log
- 分支管理模型
- master 分支
- develop 分支
- feature 分支
- release 分支
- hotfix 分支
分支管理
查看分支
// 查看本地的分支
git branch
// 查看所有分支，本地和远程服务器
git branch -a
// 切换到develop分支
git checkout develop
本地分支创建
场景：新建一个功能/bugfix 分支
// 在当前分支创建并切换到feture_new
git checkout -b feture_new
拉取服务器的新分支到本地
场景：服务端多了一个新分支，想拉取下来合并，并解决冲突
git fetch origin develop
// git pull origin develop= git fetch origin develop+ git merge origin develop
git checkout -b develop origin/develop
提交
关于commit message格式规范的问题：git commit -m "[type] commit message"。如果是新功能，type=add；如果是bug修复type=bug，如果是合并分支type=merge...新功能提交，尽量描述增加了哪些新功能，罗列出来，bug也是如此。如此做法的一个好处是查看日志的时候知道每次的提交是什么，修改了哪里。
add-commit
git add .
git commit -m "[add] message"
合并分支时，将多个commit合并为一个
场景：新功能开发分支，按计划有很多个commit，完成开发后，合并到主分支，这时候不需要那么多commit，只需要一个即可。
git merge --squash other_branch
git commit -m "[your commit]"
选择合并某一个commit
场景：需要合并另一个分支上的某一个commit
// 查找要合并的commitId
git log
// 合并
git cherry-pick commitId
打tag
场景：发布版本后，release 分支合并到 develop 分支和 master分支，在master分支上打tag
// 2.0.0 是本次版本的版本号
git tag -a 2.0.0
解决冲突
在所冲突的文件中修改，解决冲突
在代码文件中解决冲突
git add .
git commit -m ""
使用本分支/合并的分支覆盖
如果是zip文件，显然是无法使用上面的方法解决冲突，这时候只能以某个分支上的更新覆盖
// 使用本分支的覆盖
git checkout --ours -- path/to/file
// 使用要合并的分支覆盖
git checkout --theirs -- path/to/file
版本回退
回滚到某个commit
使用场景：不小心提交了一个commit，然后想回退
// 先查看commit列表
git log
// 回滚到某个Log的commitId
git reset --hard commitId
回滚到某次操作
使用场景：不小心执行了很多操作，例如回退到某个commit，现在又反悔，想回退到那个commit。git的任何操作都可以反悔
// 查看操作日志
git log
// 回滚到某个操作
git reset --hard commitId
查看日志
log
git log [<options>] [<revision range>] [[\--] <path>…]
git reflog
分支管理模型
参考这篇文章：一个成功的 Git 分支模型，分支管理模型，主要围绕五个分支，理解它们的场景和生命周期，就基本理解整个模型。
master 分支
master 分支上的代码永远是可发行的，每发一个版本，须要将release分支合并到develop分支和master分支，然后在master分支上打一个tag。
develop 分支
整合分支，下一个版本中需要开发的功能，发出去的版本需要修复的bug，最后都需要合并到develop。所有功能开发完成，可以发版本了，从develop分支创建release分支。
feature 分支
特性分支，开发一个新功能时，从develop创建，开发完成后合并到develop分支，然后删除该feature分支。
release 分支
所有功能开发完成合并到develop分支后，可以发版本了，从develop分支创建release分支，release分支可以修改一些小bug，版本发布完成后，需要合并到develop分支和master分支，然后在master分支上打tag。
hotfix 分支
已发行的最新版本中出现了bug，这时需要从master分支上创建 hotfix 分支。修改完bug后，打上新的版本号，然后发布bugfix版本。完成后需要将hotfix 分支合并到develop 分支和master 分支，并在master分支上打tag
