什么是Git？
Git直译是“笨蛋、饭桶”，是天才开发、世界上最活跃的开发者使用的版本管理系统。 就像Geek这个词一样，可能是黑色幽默。
在这里简单介绍一下。 详情请参照资料。 本文主要说明使用中的几个问题。
Git是免费的开源分布式版本控制系统，用于敏捷高效地处理小型或大型项目。 Git的读法是/gt/。
Git是一个开放源代码的分布式版本控制系统，可以高效、高速地处理非常小的项目版本控制。 Git是Linus Torvalds为帮助管理Linux内核开发而开发的开源版本控制软件。
一般基本命令
git init :初始化
git克隆：克隆
git status :显示状态
获取添加：添加
git commit :提交
git pull :拉
推送：推送
这些命令比较简单，只要稍微查一下资料就可以正常使用。
有点复杂的基本指令
git log:显示所有提交记录。
git tag:在客户端开发时经常考虑到版本。 使用git tag v1.0，可以在当前代码状态下创建新的v1.0标签，使用git tag可以显示当前的所有标签。 使用git checkout v1.1时，将切换为v1.1的代码状态。
git diff:比较当前文件和转移区域的差异、两次提交的差异、两个分支的差异以及两个版本库的差异。
git checkout:切换、checkout可以进行标签切换、分支。 checkout还可以取消暂存区中尚未包含add的代码。 例如，git checkout readme.md可以取消对md文档所做的更改。
git RM--从缓存：转移区删除等待提交的代码
git远程添加原始测试：的本地仓库与远程名为tes的t仓库相关联
别名alias
经常使用Git时，输入命令需要时间。 特别是对于较长的命令，用户可以自定义别名以简化命令。 例如，git config--全球别名. coche cout
git config---- global alias.cicommitgitconfig---global alias.PSM ' pushoriginmaster ' git config---global alias.ppplias
本文将讨论一个重点：团队合作。
分支
什么是分支？ 为什么需要分叉？
如果一个产品只有一个代码，需要多人开发，任何人对该代码进行自由修改，都会产生混乱，不是吗？
在这种情况下，必须使用分支以防止项目组中的不同开发人员相互独立和相互干扰。 在云中，首先需要代码的来源。 我们称之为“主分歧(master )”。 就像青藏高原的巴颜喀喇山脉在黄河上一样。 另一个重要的分支是开发分支(develop )。
主人：随时准备发行状态develop :最新的开发状态
初步协调小组
在线上一般预约master、develop两个分支，开发者先从master分支下拉代码，然后在本地根据master新制作本地的开发分支，然后开发
在本地完成开发内容时，将本地开发集成到本地master，将本地master推送到在线master，切换到本地开发，将本地开发集成到在线开发(有点别扭，其实是两步) ) )。
如果本地仅开发了一半，则可以将本地开发推送到在线开发。
命令行
在git分支测试：上创建新的测试分支。 另外，创建的分支基于当前分支。
git检查输出测试：将切换到分支测试。
git checkout-b test:将上述两个步骤合并为一个步骤。
git push origin测试：将本地测试分支推送到远程仓库。
git branch:显示本地分支的列表。
git分支- r :显示远程分支的列表。
git分支测试：将删除本地分支测试。
git分支- d测试：强制删除本地分支。 为什么要强制删除？ 因为有时不能正常删除。 例如，您的test分支本身中存在尚未合并的代码。 在这种情况下，如果尝试使用git branch-d a，则无法删除此分支。 显示智能提示。
git push origin :测试：删除远程分支。
gitcheckoutdeveloporigin /开发
:将远程分支迁移到本地。合并
合并有两种方式： 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 推出的一套工具，简化命令。开源地址：https://github.com/nvie/gitflow