git学习

git学习——第1节 git初识-CSDN博客

git学习——第2节 时光机穿梭-CSDN博客

git学习——第3节 远程仓库-CSDN博客

git学习——第4.1节 分支管理之创建与合并分支-CSDN博客

git学习——第4.2节 分支管理之解决冲突-CSDN博客

git学习——第4.3节 分支管理之分支管理策略-CSDN博客

git学习——第4.4节 分支管理之 Bug分支-CSDN博客

git学习——第4.5节 分支管理之Feature分支-CSDN博客

git学习——第4.6节 分支管理之多人协作-CSDN博客

git学习——第4.7节 分支管理之Rebase-CSDN博客

一些名词

1 工作区（Working Directory）

就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：

2 版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

一些命令：

1 git diff HEAD -- file

git diff HEAD -- readme.txt

提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别

2 git checkout -- file

修改了文件，发现了错误，但是此时没有提交到缓存区（没有git add）

# 1手动改
# 2
git checkout -- readme.txt

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

3 git reset HEAD file

文件有错误，但是此时已经提交到缓存区了（已经git add），但是没有commit

用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

git reset HEAD readme.txt

4 git rm file

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了，再用命令git rm删掉，并且git commit

git rm test.txt

现在，文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git checkout -- test.txt

5 git log

git log命令显示从最近到最远的提交日志

git log
git log --pretty=oneline

6 回退版本

上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

git reset --hard HEAD^
git reset --hard 1094a        # 指定版本

7 git reflog

在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

git reflog

8 git checkout

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch dev
git checkout dev
Switched to branch 'dev'

9 git branch

用git branch命令查看当前分支，git branch命令会列出所有分支，当前分支前面会标一个*号。

git branch
* dev
  master

10 切换分支

现在，dev分支的工作完成，我们就可以切换回master分支：

git checkout master
Switched to branch 'master'

11 git merge dev

我们把dev分支的工作成果合并到master分支上，在master分支上

git merge dev

12 删除分支

合并完成后，就可以放心地删除dev分支了：

git branch -d dev

13 switch

创建并切换到新的dev分支，可以使用：

git switch -c dev

直接切换到已有的master分支，可以使用：

git switch master

14 分支的合并情况

git log --graph --pretty=oneline --abbrev-commit

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

15 git status

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交。并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash
Saved working directory and index state WIP on dev: f52c633 add merge

刚才的工作现场存到哪去了？用git stash list命令看看：

16 git stash list

git stash list
stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

git stash pop

17 cherry-pick【重点】

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？

有木有更简单的方法？

有！

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

git cherry-pick 4c805e2

用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

18 git branch -D

删除没有合并的分支。

git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。

git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).

19 git remote

要查看远程库的信息，

git remote
git remote -v

20 多人协作

多人协作的工作模式通常是这样：

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

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

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

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

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

21 git rebase

原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。git rebase前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。

这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。