Git常用操作和工作流程的总结
一、分布式版本控制
去“中心化”，每一台电脑都能充当中央仓库，可以模拟实现本地版本控制和集中式版本控制。
1.1 Git与SVN
SVN图解
版本集中在中央仓库，所有迭代依赖网络，所有commit需提交到中央仓库实现更新。
其他VCS存储信息基于文件变化，而Git将数据认为是一个个快照，将一系列文件快照合起来组成一个小型的文件系统，这一系列数据形成了“快照流”，由Git统一管理。
基于Git的所有操作都能找到历史版本，形成工作流。在使用其他VCS时，如果没有提交，很容易出现数据丢失的情况。而在Git中，可以将某一阶段的工作存为一个快照，这样能很好的避免数据丢失。
Git流图解
前面说到每次add, commit操作后对应一个snapshot，每一snapshot 对应一个“指针”，可以用git log查看
如图，黄色部分就是“指针”，白色部分是每次提交的“注释”
基本操作
- 文件修改后 add
将文件提交到staged区域（也可以理解问本地仓库） - commit后，push 将staged区域的文件提交到“中央仓库”（任意设定的一台PC作为中央仓库）
- Pull 从中央仓库拉取到本地
常用到的命令：
git add remote “名称” “远程仓库名称.git”
git add + “filename”
git commit -a -m “注释”
-a 确认所有已经修改了所有文件
-m 添加注释
git push -u 远程服务器 本地分支
-u 设置默认推送的远程服务器和本地分支 下次可以直接使用git push
git pull 远程服务器 远程分支
二、常用的工作流
2.1 以集中式工作流为基础的分支形式
开发者发布修改到正式项目中，开发者要把本地master分支的修改 push到中央仓库中。这相当于svn commit操作，但push操作会把所有还不在中央仓库的本地提交都推上去
在提交自己功能修改到中央库前，需要先pull在中央库的新增提交，rebase自己提交到中央库提交历史之上。
git pull –rebase origin master
如果你忘加了rebase选项，pull操作仍然可以完成，但每次pull操作要同步中央仓库中别人修改时，提交历史会以一个多余的合并提交结尾。 对于集中式工作流，最好是使用rebase而不是生成一个合并提交
2.2 功能版本流分支
基本功能分支
- 每条分支单独来看都是集中式
- mater作为develop的父分支，可以认为是历史发布版本的分支
- develop从master拉出，作为功能集成的分支
- feature以develop为父分支，在完成功能后，合并回develop分支
升级版功能分支
- 在基础版本上增加了热修复分支，作为快速为master版本的bug做及时修复
- release分支作为提测打包、Code Review 的分支
2.3 Forking工作流（开源软件常用）
pull request
在每次新的push之后，可以在Git上提pull request进行讨论，并且可以用Github提供的hook集成进协同办公软件通知组内成员。
folk后贡献自己的代码
点击folk之后会将你想要参与的工程进行备份在自己的账号下，再进行clone后就可以在本地进行修改。
当修改完成后可以可以push到自己的远程仓库，像原项目提pull request进行代码merge的请求。
如果原作者觉得可以合并到项目中，进行merge后，代码则合并在工程中。