git学习之路
git学习之路目录
git基础知识
关于版本控制
本地版本控制系统
集中化的版本控制系统
分布式版本控制系统
git安装和初始配置
git版本库创建 添加 修改文件
git常用操作详解
一般开发流程
git版本回退操作
git分支管理
分支创建
分支切换
分支查看
分支删除
分支合并merge
分支变基rebase
分支合并冲突解决
分支bug修复
分支推送（多人协作）
附录：学习资料
git基础知识
关于版本控制
什么是“版本控制”？我为什么要关心它呢？ 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 在本书所展示的例子中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。
如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。 有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
Figure 1. 本地版本控制.
其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
集中化的版本控制系统
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。
Figure 2. 集中化的版本控制.
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
Figure 3. 分布式版本控制.
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
git安装和初始配置
git版本库创建 添加 修改文件
git常用操作详解
一般开发流程
安装最新版本的Git软件安装到本地：https://www.git-scm.com/download/
注册GitHub账号密码：https://github.com/maixiquan
创建GitHub代码仓库：首先在GitHub上创建自己的仓库，进入GitHub官网并登陆，点击 New repository
然后输入自己的仓库名称及仓库说明，输入完毕后点击 Create repository，点击Clone or dowload会出现一个地址，copy这个地址备用
回到电脑，打开终端，
（常见命令）
git clone 仓库地址
git branch 拉分支
修改代码abcdefg。。。。。。。
git diff (查看修改的内容）
git status (查看状态）
git add . （后面的 . 是把该文件夹下面的文件都添加进来）
git commit -m "提交信息" （“提交信息”是自定义的，如“first commit”）
git pull origin master （先使用pull，进行合并然后再进行push，即先使用pull将远程文件同步下来。）
git push -u origin master （此操作目的是把本地仓库push到github上面，此步骤需要你输入帐号和密码）
git reset HEAD~1（返回操作）
git版本回退操作
git reset HEAD//回退到上一个版本
git reset --hard commit_id//回退到commit_id版本，并且把修改删除，慎重操作
用git log可以查看提交历史，以便确定要回到之前的哪个版本。
用git reflog查看命令历史，以便确定要回到未来的哪个版本。
git分支管理
几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。有人把 Git 的分支模型称为必杀技特性，而正是因为它，将 Git 从版本控制系统家族里区分出来。
创建项目时（一般是服务型项目，工具型或辅助型项目可以简单一些），会针对不同环境创建三个常设分支：
- develop：开发环境的稳定分支，公共开发环境基于该分支构建。
- pre-release：测试环境的稳定分支，测试环境基于该分支构建。
- master：生产环境的稳定分支，生产环境基于该分支构建。仅用来发布新版本，除了从pre-release或生产环境Bug修复分支进行merge，不接受任何其它修改
平时开发工作中，会根据需要由开发人员创建两类临时分支：
- 功能（feature）分支：为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature-*的形式命名(*为任务单号)
- Bug修复（fixbug）分支：为了修复某个bug，从常设分支上面分出来的。修复完成后，再merge到对应的分支。Bug修复分支的命名，可以采用fixbug-*的形式命名（*为bug单号）
你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
分支创建
使用 git branch
git branch testing
用于开发新的feature，最好新建一个分支
分支切换
使用 git checkout HEAD 就指向 testing 分支
git checkout testing
注：git通过HEAD 的特殊指针知道当前在哪一个分支上。HEAD 指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。
新建一个分支并同时切换到那个分支上，你可以运行一个带有 -b 参数的 git checkout -b
git checkout -b temp
相当于两条命令的合并：git branch temp；git checkout temp
分支查看
直接使用 git branch 命令，会列出所有分支，当前分支前面会标一个*号。
稍微做些修改并提交：
vim test.txt
git commit -a -m "branch test"
分支删除
使用git branch -d 命令
git branch -d testing
分支合并merge
使用git merge 命令，将
例子，将testing分支合并到master分支，如下
git checkout master
git merge testing
分支变基rebase
相似的概念是Merge，但是变基实现方式并不是合并，而是重放，既将分支A的提交在分支B上重新提交一遍。
git checkout bugFix//切换到修复的分支
git checkout master//将修复的分支重放到master上（提交内容相同，但是校验和不同)
这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。
分支合并冲突解决
既然你的修改已经合并进来了，就不再需要 testing 分支了。 现在你可以在任务追踪系统中关闭此项任务，并删除这个分支。
git branch -d testing
有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 分支的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突。此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件
上述的冲突解决方案是仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。
用带参数的git log也可以看到分支的合并情况，git log --graph --pretty=oneline --abbrev-commit
分支bug修复
- 如果修改一个分支过程中突然修改另外的分支：
- git status
- git stash //暂存
- git checkout 拉另外的分支
- 修改代码abcdefg。。。。。。。
- 打包上传
- git checkout 继续之前的拉另外的分支
- git stash pop //推出暂存
分支推送（多人协作）
- 查看远程库信息，使用git remote -v；本地新建的分支如果不推送到远程，对其他人就是不可见的；
- 首先，可以试图用git push origin < branch-name > 推送自己的修改；
- 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
- 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用git push origin < branch-name >推送就能成功！
- 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to < branch-name > origin/< branch-name >。
附录：学习资料
可视化工具：https://learngitbranching.js.org/?locale=zh_CN
学习资料：https://www.git-scm.com/book/zh/v2