git的工作流

1、克隆 Git 资源作为工作目录。
2、在克隆的资源上添加或修改文件。
3、如果其他人修改了，你可以更新资源。
4、在提交前查看修改。
5、提交修改。
6、在修改完成后，如果发现错误，可以撤回提交并再次修改并提交

基本概念

资源库

    这个就是类似于一个简单的数据库，我们本地仓库创建的.git文件夹就包含了所有的仓库信息，这个信息是包含每次修订和历史信息的全部内容。

分支

   几乎所有的版本控制系统都以某种形式支持分支。而分支是git的灵魂所在；我们会经常的创建不同的分支处理和解决不同的问题，同时会对分支进行管理来实现代码的管理；

标签

   这里我们的项目如果达到一个重要阶段，或是里程碑或是每一次小的项目阶段或是我们一个需求的上线可能都要打一个标签。这个标签可以代表我们阶段的稳定性。基本上每次tag都是基于master的最新版本，当然Git也是支持后补Tag的，只要基于commitid就可以打任一阶段的标签。

远程仓库

  通常我们所做得各种操作基本上都是在本地执行，如果你想通过 Git 分享你的代码或者与其他开发人员合作。 你就需要将数据放到一台其他开发人员能够连接的服务器上。

   实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

   类似于有名的GitHub或者开源中国（码云）等；其实远程仓库的代码和本地仓库的代码是完全相同的东西，不同之处是24小时开机方便协同开发人员的代码；

工作区、暂存区、本地仓库

【Workspace：工作区(本地项目的工作空间)】
【Index / Stage：暂存区】
【Repository：仓库区（本地仓库）】
【Remote：远程仓库】
我们开发的代码会不停的在这几个区域中存在。

工作区其实就是我们的编写程序的地方，也就是出了.Git文件夹里得内容的之外的所有文件和文件夹，我们所有编写的代码都在这里面。

然后本地仓库其实包含了暂存区和分支两部分，暂存区其实就是我们每次提交之前先进行的git add操作之后的一个待提交列表的一个区域，这样说不太好的是这里面不单纯是一个列表，可以认为是一个但提交列表的一个文件区域。

分支部分就是咱们版本库最重要的概念，里面存放了我们的所有分支和操作记录，其中的master也是一个分支。从暂存区commit之后就进入到了版本库中。

Git中文件的4种状态

git库所在的文件夹中的文件大致有4种状态

• Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged.
  
• Unmodify: 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件
  
• Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改
  
• Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified
  

stash（工作暂存）

stash命令可用于临时保存和回复修改，可跨分支, 一般用于保存和恢复工作进度的场景；比如正在完成功能的过程中但是还没有完成，这个时候需要修复一个紧急bug；

1. 可以切一个新分支进行修改，提交代码，然后切回分支继续完成新功能；
2. 也可以使用stash，把当前正在进行的工作暂存起来，然后修复bug，修复完成后，在把stash中的正在进行中的工作恢复回来，然后继续工作；

这两种方式都是可以的，自己会用那种方式都可行；

Merge合并代码

合并指定分支到当前分支，以实现代码的同步和协作；

rebase 变基

将其他分支的代码安装最开始的顺序放在自己的分支中，同时将过去自己的提交按顺序放在后面，并保持顺序；

PR（pull request）

GIT中的Pull Request模式（简称PR）
PR是开发者使用git进行协作的利器。
PR是协作者修改代码后或在原基础上增加新代码后向仓库发送采纳的请求功能 。
协作者提交PR的时候可以选择审核人（对当前分支有管理权限的人）进行审核，审核过后，源分支代码（协助者修改代码所在的分支）会自动合并到目标分支
前提：源分支和目标分支不存在冲突，否则合并失败，需要手动操作；

CP（cherry Pick）

这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（git merge）。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 Cherry pick。

Cherry pick 可以让我们选择正确的提交合并到当前分支；