什么是Git？
Git直接翻译是「蠢货，饭桶」，然而却是由天才开发出来的，被全世界最活跃的开发者使用的版本管理系统。可能是一些黑色幽默吧，就像Geek这个词一样。
这里简单介绍一下，详情请查阅资料，本文主要是要讲解一下使用中的一些问题。
Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。 Git的读音为/gɪt/。
Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
常用基本命令
git init：初始化
git clone：克隆
git status：查看状态
git add：添加
git commit：提交
git pull：拉
git push：推
以上几个命令比较简单，略微查下资料即可顺利使用。
稍复杂基本命令
git log: 查看所有commit记录。
git tag: 在进行客户端开发时，常会考虑到版本。使用git tag v1.0,那么就在当前代码状态下新建了一个v1.0的标签，使用git tag可以查看当前所有标签。使用git checkout v1.1的话，那么就切换到v1.1的代码状态下。
git diff: 比较当前文件和暂存区的差异，两次commit之间的差异，两条分支之间的差异，两个版本库之间的差异。
git checkout: 切换，checkout可以切换标签，分支。checkout还能撤销还没有add进暂存区的代码，比如git checkout readme.md即可撤销对于md文档的改动。
git rm --cached: 移除暂存区中等待提交的代码
git remote add origin test: 本地仓库与远程名为tes的t仓库进行关联
别名alias
当经常使用Git时，会在输入命令上消耗一些时间，尤其是一些比较长的命令，这时候用户可以自定义别名，用来简化命令。比如：
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
下面是这篇文章所要讲的重点：团队协作。
分支
- 什么是分支？为什么需要分支？
可以设想这么一个情况，假如一款产品只有一份代码，而需要多人开发，那么每个人都在这一份代码上随意修改，那岂不是乱了套？
这时候我们就需要用到分支，使一个项目组中的不同开发者相互独立，互不干扰。
在云端，首先需要一份代码之源，我们称之为：主分支（master），犹如青藏高原巴颜喀拉山脉之于黄河。另外一条重要分支是开发分支（develop）。
可以概括为：
master：随时处于准备发布状态
develop：最新的开发状态
- 初步协调团队
线上一般保留master，develop两条分支，开发者首先从master分支pull下代码，然后在本地基于master再新建本地develop分支，然后在develop分支上进行开发。
- 若在本地完成开发内容，可以将本地develop合并到本地master，将本地master推到线上master，切换回本地develop，将本地develop推到线上develop。（有点拗口，其实就两个步骤）
- 若在本地只开发到一半，可以将本地develop推到线上develop。
- 命令行
-
git branch test:新建test分支。需要提一下的是，所建分支是基于当前分支的。 -
git checkout test:切换到分支test。 -
git checkout -b test:将上述两步合为一步。 -
git push origin test:将本地test分支推送到远程仓库。 -
git branch:查看本地分支列表。 -
git branch -r:查看远端分支列表。 -
git branch -d test:删除本地分支test。 -
git branch -D test: 强制删除本地分支,为什么要强制删除？因为在一些情况下是无法常规删除的，比如：你的test分支本身还存在未合并的代码，此时想要使用git branch -d a是无法删除这个分支的，会出现智能提示。 -
git push origin :test:删除远程分支。 -
git checkout develop origin/develop:将远程分支迁移到本地。
合并
合并有两种方式：merge rebase
- merge
假如在test分支上进行开发，开发完成后想要把分支合并到master分支。
- 首先需要切换到master分支
git checkout master -
git merge test不出意外就能将test分支合并进来，但是需要考虑意外情况：发生版本冲突。
- rebase
rebase和merge有异曲同工之处，使用rebase也能达到合并分支的效果。
git checkout master
git rebase test
但是这两点的差异在哪？这是stormzhang的一个比喻：
rebase跟merge的区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，第一种做法是merge，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进 去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；第二种做法就是rebase，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置 好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。
冲突
两个人在两条分支上开发不同的功能，然后依次合并到主分支，一般来说两人各司其职是不会出现问题的。但是有些情况，两个人对同一块公共代码进行了更改，比如工具类。
此时第一个人可以顺利合并master，但是第二个人提交时会出现冲突，需要手动解决冲突才能顺利合并。
在解决冲突问题时，我们可以根据提示的代码差异进行更改后重新提交。
Stash
假如我们已经在一个分支开发到了一半，现在需要切换到别的分支去完成一些任务，那么现在当前的代码如何保留呢？
此时需要用到stash，当然前提是没有commit。
首先执行 git stash
此时会将还没有commit的代码保存到一个暂存区，此时执行git status查看，会发现当前分支没有等待提交的代码。
git stash list可以 查看暂存区有多少条记录（一条分支暂存的所有代码只会生成一条记录）
此时可以切换到其他分支，将任务完成，再切回到原来的分支，此时，如何将未提交的代码还原？
执行git stash apply,然后使用git stash drop将暂存区的记录删除。
而git stash pop相当于将上述两步变为一步。
进阶协调
理想化的状态是这样：比如有三个人开发一款产品，那三个人分别创建三个分支，在各自的分支上完成后合依次合并到master。而现实情况的干扰因素却多得多。这时候需要用到分支管理流程GitFlow。
- 一般状态下有两个主要分支：
master：随时处于准备发布状态
develop：最新的开发状态
如果出现了线上版本出现严重bug需要紧急修复，或者某些功能完成后出现了需求变更，这时，需要再引入三个辅助分支。
-
feature: 开发新功能的分支, 基于develop, 完成后merge回develop -
release: 准备要发布版本的分支, 用来修复 bug，基于develop，完成后merge回develop和master -
hotfix: 修复master上的问题,紧急情况， 等不及release版本就必须马上上线. 基于master, 完成后merge回master和develop
情景：
假如我们现在的项目有master和develop分支
现在我准备开发一个登录功能，B同学准备开发一个注册功能，那么我需要基于
develop分支新建git branch feature/login,B同学需要基于develop新建git branch feature/register比如突然说线上版本的图片显示出了bug，需要紧急修复，尽快上线，那么需要在
master分支下执行git branch hotfix/imgDisplay,修复完成后合并到master和develop如果某一阶段开发的差不多了，功能都已经合并到了
develop，现在需要对develop上的代码进行一个整体的测试，假如测试通过，可以发布到正式环境，此时可以基于develop新建一个分支git branch release/v1.0
这是一个规范化的分支管理流程，可能在小团队的开发中，有些步骤可以忽略，但是我建议还是按照这一套逻辑管理代码会更为高效。
当然，如果你觉得输入这些命令很麻烦，尤其是可以将命令行合并为命令块的情况，你可以使用gitflow[图片上传中...(git2.jpg-5e9156-1516778428798-0)]
推出的一套工具，简化命令。开源地址：https://github.com/nvie/gitflow