git版本控制以及分支管理

git版本控制以及分支管理--一起乘坐时光机

四.深度剖析
- 一.版本控制---时光机穿梭
- - 1.熟悉版本
  - 2.版本回退
  - 3.管理修改
  - - 1.管理修改以及理解工作的原理
    - 2.撤销修改的内容
    - 3.删除文件
- 二.分支管理
- - 1.分支基本操作
  - 2.解决分支冲突
  - 3.分支合并管理
  - 4.解决bug分支

四.深度剖析

何为版本控制：git的传奇之处

每当我们对我们的文件做一项操作时，但是我们又想回到之前的操作，那么这个时候已经过了好久，怎么办，机器控制版本的时代到来，git就能够精妙的控制文件的每次改动。就像下图这样

版本	文件名	用户	说明	日期
1	service.doc	张三	删除了软件服务条款5	7/12 10:38
2	service.doc	张三	增加了License人数限制	7/12 18:09
3	service.doc	李四	财务部门调整了合同金额	7/13 9:51
4	service.doc	张三	延长了免费升级周期	7/14 15:17

我们在上文已经知道git简单的日常操作流程，那么接下来就开始进入git的不平凡之处。

一.版本控制—时光机穿梭

1.熟悉版本

git可以记录我们每次的修改，当我们修改了文件，git就会有一条记录，记录我们的修改，以便于我们在旅游出差回来还能够找到修改的内容。

命令一：

$git status  //查看当前的仓库的状态 可以查询我们的修改

但是git status 并不能够查看我们修改的内容这个时候就需要 git diff

$git diff //查看修改的内容

我们知道修改的内容之后我们就可以根据需要看是否提交或者是否修改

$ git add Testthree.txt //提交当前的文件到暂存区

提交到本地仓库

$ git commit -m "我的第三次测试"

2.版本回退

我们刚刚提交的内容，也许我们不会记得我们修改的什么内容，这个时候就需要我们查看我们的修改历史，git log 可以查看最近到最远的提交日志

$ git log  //

$ git log --pretty=oneline  //更清晰的查看

注：如果commit（提交）比较多，git log 的内容就会比较多；当满屏放不下，就会显示冒号，回车（往下滚一行）、空格（往下滚一页）可以继续查看剩余内容；退出：英文状态下按 q 可以退出git log 状态。

版本回退

首先我们要知道我们当前所处的版本，HEAD表示的是当前的版本，上一个版本就是 HEAD^{,上上个版本就是HEAD}^,前面的一百个版本就是HEAD~100

回退命令

$ git reset --hard HEAD^  //回退到上一个版本

回退之后我们可以利用cat +当前文件夹查看内容是否回退

$ cat readme.txt //查看当前的内容

利用 git log 查询当前的所处版本会发现没有了我们修改之前所处的版本，回不去了！！！！

那是不可能滴

只要命令行没有关掉，我们可以找到当时的版本的提交id commit -id

我们就可以指定版本回到那个位置

$  git reset --hard 263395  //后面的263395是版本号 可以输入全部 也可以输入前几位，前提版本少可以找的到
HEAD is now at 2633959 你好

我们可以i看到已经回退到我们当时所处的版本，所以git 可以让我们在时空里来回穿梭。

HEAD 指向示意图
修改之后

wait wait 如果我们关掉了命令行，想要回到过去怎么搞？？？！！

查看命令历史

$ git reflog

look 以上就是我们的提交的命令历史

我们乘着时光机又回来了。

3.管理修改

1.管理修改以及理解工作的原理

小前提 --理解什么是暂存区以及工作区

工作区：电脑上你的目录文件区域 such as

版本库：

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

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

当我们修改工作区的文件，然后add 到暂存区，等到修改的文件足够多的时候，一并提交。

提交并且查看当前状态

$ git commit -m "understand how stage works"  //提交当前的修改
$ git status  //查看是否有需要提交的修改状态
On branch master
nothing to commit, working tree clean  //表示干净嘞很 没啥要提交的

注意----

commit 我们可以看到我们提交的只是暂存区的提交内容，若是多次修改，那么需要多次 add . 把修改的内容添加到暂存区

方便我们一次提交

2.撤销修改的内容

场景一

自修改后还没有被放到暂存区

$ git checkout -- readme.txt  //git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销

撤回修改就撤回到和版本库一摸一样的状态

已经添加到暂存区后，又作了修改

销修改就回到添加到暂存区后的状态。

总而言之就是让这个文件回到最近一次的git commit 或者 git add 的状态

场景二

改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改

$ git reset HEAD readme.txt  //第一步就是 把暂存区的修改回退到工作区

然后丢弃工作区的修改利用场景一。

3.删除文件

$ rm test.txt  //删除名字为 test.txt 的文件

版本库会询问你是否真的要删除

$ git rm test.txt   //删除
rm 'test.txt'$ git commit -m "remove test.txt"  //是真的 我都提交了
[master d46f35e] remove test.txt1 file changed, 1 deletion(-)delete mode 100644 test.txt

删除错了我giao

版本库中还有，可以轻松恢复
```
$ git checkout -- test.txt
```
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

注：从来没有添加到版本库的文件是不能够被恢复

二.分支管理

每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

1.分支基本操作

创建分支命令

$git branch (branchname)  //创建分支 （1）

$ git checkout -b dev    //创建分支并且切换到dev的分支  （2）
Switched to a new branch 'dev'

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

$ git branch dev
$ git checkout dev

切换分支命令:

$git checkout (branchname)

当你切换分支的时候，Git 会用该分支的最后提交的快照替换你的工作目录的内容，所以多个分支不需要多个目录。

合并分支命令:

$git merge （合并分支的名称） 依据当前的所处分支然后合另外的分支到当前的分支

查看当前的分支带星号表示当前所处的分支

$git branch

删除分支

git branch -d <name>

2.解决分支冲突

当我们在新的分支里面修改一些东西，然后切换分支之后我们又在文件里面修改了一些内容，那么这两个分支就会发生冲突。

当 master和feature 都有新的修改内容，

尝试合并分支

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.  //发现冲突

找到发生冲突的文件，我们也可以使用

$ git status  //查看冲突的文件

我们直接到冲突的文件之后会发现

<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1   //

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改后保存：再提交

此时的状态就是这个样子的。

我们可以用查看分支合并图

git log --graph

删除分支，工作完成

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

3.分支合并管理

Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息，不能够显示我们是否合并了分支。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.readme.txt | 1 +1 file changed, 1 insertion(+)

合并之后我们可以利用

$ git log --graph --pretty=oneline --abbrev-commit   //查看分支合并图
*   commit cf20d935394b7243903aa054d8f59c5990682ee6 (HEAD -> master)
|\  Merge: b661434 0cc4463
| | Author: wangyunfei <2279567793@qq.com>
| | Date:   Sat Mar 19 11:12:26 2022 +0800
| |
| |     禁用参数Fast forward
| |
| * commit 0cc446372e7d91187677d7463015154b031f3cf1 (test)
|/  Author: wangyunfei <2279567793@qq.com>
|   Date:   Sat Mar 19 11:10:51 2022 +0800
|
|       添加新的commit
|
*   commit b6614341f8862d44b170952165caaed4eb3c7304 (dev)
|\  Merge: 001eefc 361b6fd
| | Author: wangyunfei <2279567793@qq.com>
| | Date:   Sat Mar 19 10:54:29 2022 +0800
| |
| |     解决冲突并且提交修改

如图所示，分支合并，能够被我们捕捉。

日常开发中我们要遵循的分支管理

1.master非常稳定，仅仅用来发布新版本，不能再这个上面工作

2.创建dev分支，在这个上面进行工作，然后把工作内容合并到master上面

3.每个人都在自己的分支上面工作，时不时的忘dev分支上面合并。

经典的分支合作。

4.解决bug分支

需要我们修复bug的时候，我们不能停下手中当前的分支，当前的工作没有提交怎么搞。工作做到一半！！！！

$ git status
On branch dev
Changes to be committed:  //发现我们的工作还没提交

储存我们的工作：

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

可以再次 git status 查看会发现我们的工作区是干净的简直不要太爽！

解决bug的时候，我们要明确bug的诞生位置，是在哪一个分支上面，在哪个上面就在哪个上面创建新的分支

$ git checkout master //切换分支
$ git checkout -b issue-101  //创建bug分支

修复bug 切换到master 分支，完成合并，删除分支

$ git add readme.txt   //修改之后添加到暂存区
$ git commit -m "fix bug 101"  //提交修改到当前的分支
$ git switch master //切换分支
$ git merge --no-ff -m "merged bug fix 101" issue-101 //合并bug 分支到当前的分支上面

bug 解决回到工作分支继续搞工作

$ git switch dev //切换到dev 工作分支
$ git status //查看分支状态
On branch dev
nothing to commit, working tree clean   //哎呦 我giao 干净嘞很，这可咋办

利用git stash list 查看工作现场

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

两种恢复方式:

$git stash apply

恢复，但是恢复后，stash内容并不删除 $ git stash list //可以查询到内容

$git stash pop

恢复的同时把stash内容也删了删除之后 $ git stash list //查看看不到任何的内容了

注意：你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

偷偷说一句：

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