Git 入门教程

Git，是分布式版本控制工具，分布式相对于集中式可以这样理解，集中式有一个服务器（典型的SVN），我们在自己电脑上编辑完成的版本上传到服务器，版本V1-V2-V3这样叠加，当服务器出现问题我们就没法迭代版本；而 Git作为分布式控制，它在本地有一个临时库可以用，即便服务器出问题了，我们也可以在本地迭代版本，服务器恢复了再上传远端就可以了

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

1. 安装Git

2. 创建版本库

3. 工作区状态

4. 版本回退

5. 工作区和暂缓区

1. 工作区（Working Directory）
工作区就是电脑中看到的目录，比如learngit文件夹就是一个工作区

2. 版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

3. 文件添加到Git版本库
1. 第一步是用git add添加进去，实际是把文件添加到暂存区
2. 第二步是用git commit提交更改，实际是把暂存区的所有内容提交到当前分支
3. 因为当创建Git版本库时，Git自动创建了唯一一个master分支，所以git commit就是往master分支上提交更改

6. 管理修改

Git控制系统的优秀之处：Git跟踪并管理的是修改，而非文件 修改：新增一行、删除一行、更改字符、删除增加、创建新文件等都是修改

7. 撤销修改

1. 文件只在工作区操作，未进行add操作：

1. 文件已经进行add操作，但未进行commit操作：

1. 文件不但进行了add操作，而且还进行了commit操作：

8. 删除文件

9. 添加/删除远程库（Github）

1. 登录Github账户，新建存储库（New respository）

2. 设置Repository name，然后Create repository

3. 创建完成后，获取仓库地址

10. 从远程库克隆

11. 分支管理

👉分支介绍

😮分支的作用

💪分支的优点

12. 创建与合并分支

• 在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

• 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

• 每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

• 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

• 你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

• 不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

• 假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

• 所以Git合并分支也很快！就改改指针，工作区内容也不变！

• 合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

• 举例实战：

• 切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

13. 解决冲突

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。

• 现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

• 这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

14. 分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。 如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

分支策略

1. 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

2. 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

3. 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

15. Bug分支

1. 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

2. 当手头工作没有完成时，先把工作现场 git stash一下，然后去修复bug，修复后，再 git stash pop，回到工作现场；

3. 在master分支上修复的bug，想要合并到当前dev分支，可以用 git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

16. Feature分支

17. 多人协作

1. 首先，可以试图用 git push origin <branch-name>推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用 git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用 git push origin <branch-name>推送就能成功！

5. 如果 git pull提示 no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令 git branch --set-upstream-to <branch-name> origin/<branch-name>。

18. Rebase

19. 标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

20. 创建标签

标签是指向commit的死指针，分支是指向commit的活指针

21. 操作标签

22. 使用Github

1. 首先访问你的目标项目主页，例如https://github.com/twbs/bootstrap

2. 点击"Fork"在自己账号下克隆目标仓库，例如Bootstrap

3. 然后，从自己账号下克隆

1. Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：

1. 如果想修复目标仓库（Bootstrap）的Bug，或者新增功能，可以立即开始干活，完成后，往自己仓库推送

2. 如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。
📢
在GitHub上，可以任意Fork开源仓库； 自己拥有Fork后的仓库的读写权限； 可以推送pull request给官方仓库来贡献代码。