git 使用

Obito~

已于 2024-05-27 09:44:08 修改

阅读量12

点赞数

分类专栏： android 工具配置和操作知识文章标签： git github 服务器

于 2022-07-29 18:23:40 首次发布

本文链接：https://blog.csdn.net/weixin_43836998/article/details/126061615

版权

android 工具配置和操作知识专栏收录该内容

1 篇文章 0 订阅

订阅专栏

对一个项目git初始化

git init

这个时候会生成.git 文件,这个时候你的文件全部都是红色的，
你执行git status，或者在studio 上看全部都是红色，
这代表的你文件并没有被存放到暂存区，也代表红色文件不会有git的任何功能，单纯只是个文件被放进来

你需要对指定的需要有git 功能的文件，执行

git add xxx

这代表，你把指定文件放到了暂存区，你需要这些文件有git 功能
那么你在执行 git status 或者 studio 上看就会发现，文件变成了绿色。

当你在执行

git commit -m “project init”

git commit 代表把这一次的暂存区进行一个提交保存记录

那么你在执行 git status 会找不到修改的文件
在studio上看文件变成了白色。

如果你打算将项目存储在远程仓库中，你需要关联一个远程仓库。假设你已经在 Git 托管服务商（如 GitHub、GitLab 或 Bitbucket）上创建了一个仓库，可以使用以下命令将本地仓库与远程仓库关联：

git remote add origin <远程仓库URL>

当你通过 git clone 命令从远程仓库克隆项目时，会在本地创建一个名为 origin 的远程仓库的副本
也是对于你本地来说，远程仓库默认名字就叫做 origin
origin代表远程仓库地址的一个简称
你可以理解为origin默认就是代表远程仓库

一个git 项目初始化的代码分支默认是master分支，
通常情况下，远程分支的名称是由远程仓库名（如 origin）和远程分支名（如 master）组成的
也就是本地的分支 master,对应的远程分支就叫 origin/master

当你通过git fetch 命令，就会在本地创建远程叫做 origin/master 的分支一个副本，也就是本地也有这个
origin/master 分支，他是远程 origin/master 的一个引用。此时本地的分支 origin/master 跟 master 是不一样的。本地的 origin/master 分支是远程仓库中的 origin/master 分支在本地的引用，它代表了远程仓库中的最新提交，这个origin/master 分支就已经默认关联到远程到 origin/master 分支上了

这个时候你会想，我 git fetch 拉了远程一个副本 origin/master 分支，那后面每次 git fetch ，本地的 origin/master 他都是远程仓库最新的代码相当于同步最新效果了，并且他又自动跟远处的 origin/master关联
那后续开发，我能不能切到本地的 origin/master 上做开发，而不是原来的 master

注意你可以在 origin/master 分支上进行开发，但是这不推荐

需要注意以下几点：

origin/master 是一个远程分支的本地快照，它不是一个可编辑的分支。任何在 origin/master 分支上的修改都会被视为不可推送的本地修改。

origin/master 的作用更多是为了拉取远程 origin/master的代码，让本地的origin/master 保持最新，最后关键是
把本地的origin/master 修改同步到本地的master 分支上，然后继续在 master 上开发

也就是合代码的时候，保险做法就是要先执行一遍 git fetch 不管你是不是已经git fetch 的把远程的 origin/master 拉倒本地的了
git fetch // 的目的更是为了让保证远程的代码跟本地的 origin/master 代码一致
git branch -a
git reset --hard origin/master // 然后在执行，这个就真正让当前分支= origin/master =远程代码的分支
也就是执行让当前代码本远程代码一致

总结来说，尽管你可以在 origin/master 分支上进行开发，但它是一个本地分支的快照，不推荐直接在此分支上进行修改。推荐的做法是在本地的 master 分支上进行开发，并定期更新和合并 origin/master 分支以保持同步。

当你希望把你的本地master分支提交到远程的时候，

你不可以直接git pull 更新远程到本地，也不可以直接git push 推上去。
因为此时你本地的master 分支还没有跟远程的任何分支关联上去

要么就是你就每次提交或者拉取的时候手动指定 git pull origin master 分支 git push origin master 分支
这代表你手动指明，你就是要把当前一个叫做master 分支推送到远程的一个叫做 origin/master 分支上

你就是要获取远程的一个叫做 origin/master 分支的代码同步到本地当前分支 master 上

上面是手动每次提交拉取都要指明的操作
还有一种方式

你需要执行的时候添加 -u

git push -u origin master

-u 的作用就是一个让本地代码分支 master 跟远程仓库名为 origin（因为默认就是 origin）的一个叫做 origin/master 分支绑定在一起

这只需要执行一次，就是还没绑定的时候，执行绑定，后续你不再需要这么麻烦，
而是直接执行 git push ,由于前面已经执行了-u 进行绑定关系了，那么后续你执行
git push 就会默认把你推送到绑定的分支上去

git push -u origin master 跟 git push --set-upstream origin master 的作用是一样的

其实提交代码真正的原始写法应该是

git push 仓库地址对应要提交的分支名

可通过命令 git remote -v 查看当前的文件他是属于那个 git 仓库的，以及它git push 的仓库地址在哪里

不过，仓库地址可以用 origin 代替这个仓库地址

git push origin master 跟 git push origin/master 区别

git push origin master的意义是把本地一个master 提交到远程仓库一个叫做origin仓库的一个叫做 origin/master 分支上

而 git push origin/master 是会尝试将本地的 origin/master 分支推送到远程仓库，这通常是不推荐的操作。

本地的 origin/master 分支是远程仓库中的 origin/master 分支在本地的引用，它代表了远程仓库中的最新提交

当你在本地master分支上，你提交到远程上去默认就会跟远处的一个叫做 origin/master 绑定在一起，
那么如果你说你不想跟远程的 origin/master，而是想跟远程的一个叫做 origin/doe ，也就是远程doe 分支绑定在一起
你可以设置为

git branch -u origin/doe

branch 代表当前分支，也就是你得checkout 到master 分支，才做上面的操作
-u 是绑定本地跟远程意义
origin/doe 是代表要跟远程的 origin/doe 进行绑定

或者执行
git branch --set-upstream-to=origin/doe
也是一样的效果

注意 git branch -u origin/doe 跟 git branch -u origin doe 还是不一样的

git branch -u origin/doe 是把本地当前的分支跟远程的一个叫做 origin/doe的分支绑定在一起

git branch -u origin doe 是把本地当前的分支跟远程默认仓库（可能这个仓库是叫做origin，这个不一定）的一个叫做 doe 的分支和在一起，有可能这个默认仓库不是 origin ,叫做 test,那么
git branch -u origin doe 的作用就是是把本地当前的分支跟远程默认仓库（test）的一个叫做 doe 绑定在一起，其实就是跟远程的一个叫做 test/doe 绑定在一起

所以说 origin 只是代词，代表远程仓库，只是远程仓库名字默认叫做 origin，所以远程的分支才叫做origin/xxx
如果远程仓库名字改为了test,那么 origin 只是代词 ,代表远程仓库名字是test 的仓库

如果你想查看当前仓库对应的本地分支跟远程的哪个分支绑定在一起
可执行命令

git branch -vv

例如，如果你的当前分支是 master，并且它与远程分支 origin/master 关联，那么命令的输出可能类似于：

  master        abcd123 [origin/master] Commit message
  branch1       1234abc [origin/branch1] Another commit message
  branch2       5678def Some commit message

在这个示例中，master 分支与 origin/master 分支关联，branch1 分支与 origin/branch1 分支关联，而 branch2 分支没有关联的远程分支

基础知识

上面已经讲了对文件操作，颜色的变化代表的意义
下面讲对一个文件内容修改，

git 分为工作区和暂存区，

一开始，是对一个文件在工作区进行内容的修改，也就是在工作区对一个文件内容进行修改，
执行 git status ,会发现，刚修改的文件会出现，并且是红色的，
对于studio而言，他会变成蓝色颜色
当你 git add 了，就是把这个文件此次修改放到了暂存区，也就是add 之后才变成暂存区

这个时候你执行 git status ,会发现，刚修改的文件会出现并且是绿色的，对与studio而言，依旧是蓝色颜色

当 git commit 就是把暂存区的的修改提交到本地。对与studio而言，会变成跟其他文件一样的白色

如果一个文件内容原本是1 你修改了2，然后你把git add 把这个修改文件放到了暂存区，也就是你的修改已经 add 进去了

然后，你再对 add 进去的文件的 2 进行修改变成了 3 ，这个时候你不再add

而是你直接就commit
这个时候 commit 提交的只会修改成为 2.而不是 3.因为你修改3后，并没有再次git add 把2 变成 3的修改再次放到暂存区，对于暂存区而言，他只有1变成2 的修改， git commit 是把当前的暂存区修改给提交记录保存

回退操作

当学了下面的知识，你就可以不管做了什么操作，都可以回退还原

1.回退工作区的内容（也就是还没 add，还没 commit，前做的任何代码文件修改）

git checkout . 放弃所有文件工作区的修改也就是去掉还没 git add git commit 的中全部文件的修改
这里说的修改是文件内容的修改，以及文件的删除修改，都会回退回去，
但是注意在studio中你删了某个文件然后 git checkout .删掉的文件是回不来的，而你不在studio操作，而是在项目文件去删除一个文件，你 git checkout .文件就会回来，这是个坑要注意操作形式不同

上面是对全部文件的工作区回退操作的命令，下面是单独某个文件命令

git checkout – filename

还有要注意两种操作
两种情况：如果你这个文件内容原本是 1，修改变成了2 ，但是还没有git add 进去暂存区。那意思就是你只对工作区进行了修改，那么输入 git checkout – filename 就是把工作区的修改 2 清除掉回到 1。
另外一种。如果你这个文件原本是 1 修改变成了2，也 git add进去了暂存区。但是没有commit。这个时候你又对文件进行了修改变成了3 。那么再次输入 git checkout – filename 就是把工作区的修改 3 给清除掉是回到 2 而不是回到1

所以说有了而上面，你做了删除哪个文件操作，都可以用 git checkout 去还回来

回退暂存区的内容（也就是你已经add了，但是还没有commit ）

什么命令把一个已经add 的文件，退出add
有时候你会不小心把一些不需要的文件，给 git add 进去了，这个时候，如果你直接 git commit 就会把不需要的修改给提交,等待push上去去提交代码就会出现多余的代码和文件，代码审核就会过不了合不进去，重新写，
这个时候你就需要把你刚不小心add的文件给去掉add

命令就是

git reset HEAD 文件名后面跟随指定路径就可以了

上面命令是回退指定的文件暂存区
下面命令回退当前项目所有的已经add 的文件

git reset HEAD .

如果再结合上面的回退工作区的操作就是

如果你这个文件原本是 1 修改变成了2，也 git add进去了。但还没 commit 。你想回到 1
需要两部操作

先命令回退掉暂存区的修改 git reset HEAD 文件名把暂存区的修改清掉
然后命令 git checkout – 文件名把工作区的修改清掉

而如果想回退掉当前项目所有的暂存区和工作区的内容修改就是

git reset HEAD . //回退暂存区所有文件
git checkout . //回退工作区所有文件

如果你已经add ,也已经 commit,那么你要回退，也就说，你刚git commit 的一笔提交，你觉得搞错了，
有可能是 commit 信息写错了，也有可能是，提交的某个文件内容写错了，又或者是某个文件你没有放在这笔commit
中去，也就是你想重新改

这个时候，就是采用命令

git commit --amend -m “这里写重新提交的commit信息”

注意并不是直接输入上面的命令命令
如果你直接输入上面的命令，命令框会弹出一个编辑器让你修改，比较麻烦

真正的回退操作是

不管你是 commit 信息写错了，提交的某个文件内容写错了，又或者是某个文件你没有放在这笔commit 中去
你直接在对刚写错的文件直接修改你最终认为对的代码，直接 git add xxx 你刚忘了提交的文件，然后
按往常正常 git add xx文件

然后你再 git commit --amend -m “这里写重新提交的commit信息”
你会发现看历史提交记录，git log ，刚提交的那笔错的commit已经不在了
而是变成一个新的commit了

也就是当你搞错了刚提交的一个 git commit，你不需要慌，
你按正常要在当前代码上怎么修改才是对的，再去改，去 git add 然后最后不是 git commit 而是
git commit --amend -m “这里写重新提交的commit信息” 就可以了

打个比方，我在最新的刚刚做的一笔提交test commit 中，多写了一行日志,并且commit 信息也写的不好要修改

在这里插入图片描述

这个时候，我只需要在这已经commit的基础上，把这个行日志删了
然后再 git add , git commit --amend -m “重写对的commit信息” 就可以了

在这里插入图片描述
然后你看历史提交记录，刚刚那个test 的commit已经没有了，变了刚刚你重新提交的commit的了

上面的回退是修改最新刚刚提交的commit的内容和commit信息，如果你是想回退到历史提交记录的某一个commitid

git reset --hard commitid 去回退指定的commit

–hard 代表的是硬回退的意思
–soft 代表的是软回退的意思

硬回退reset --hard 就是把你的代码直接强制到指定的 commit ,那些跟指定的 commit 不同的代码会被直接删掉
软回退reset --soft 就是把你的代码直接强制到指定的 commit ,**那些跟指定的 commit 不同的代码不会被直接删掉，而是回退到还没 git commit 的状态，你可以理解为，你软回退到哪笔commit修改，然后当前项目代码情况
是在你软回退到的那笔commit修改中添加修改了跟指定的 commit 不同的代码

打个比方
我直接通过 git reset --soft 4dda38b 回退到项目初始化那笔提交，那么项目初始化那笔提交后面的那些commit 的代码修改，还是存在的，只是他们还没有 git commit，全部都只在 git add 暂存区状态

在这里插入图片描述

大部分时候你需要保持本地代码跟等待提交的远程代码保持一致，

可通过 git branch -a 查看远程分支。然后

git reset --hard 远程分支让本地跟远程的代码一致。

每笔提交都会有个提交记录以及commit id

你可以通过git log 去查看提交过了多少记录

在这里插入图片描述
每个commit 都是个独一的 id

git reset --hard commitid 就可以回退到以前的某个commit 的版本。
但是比如你回到 8月8的 commit 的提交。你8月9后面的 commit 都不会不见了。数据也当然不见。
因为你采用的是 --hard 强回退
你用 git log 查看commit 也看不到 8月9后面的 commit
这个时候如果你发现我错了。我不应该回退。 8月9是个好的commit 。
我要回退到8月9的commit去
这个时候你需要的就寻找 8月9的 commit id ，然后在 git reset --hard commitid 回退到 8月9的提交记录上

git 中每一个个操作他都是有一个对应的 commitid
包括你执行了

git commit
git commit --amend
git reset --hard commitid

他都是用每一个个 commitid,来记录的，就算你
利用 git commit --amend 去更改
利用 git reset --hard commitid 去做回退操作

其实实际也是重新生成了一个新的 commitid.

用命令

git reflog

这个命令是很强大的命令，他可以列出你对commit的所有操作记录，
就算是包括 git commit git commit --amend 还是上面的 git reset --hard commitid
这些对 commit 的操作他都通通记得

就如下面的图，最左边的黄色字符串就是一个个操作的commitId
一开始的 git reset --hard commitid 这个操作都有个 commitid 就是 1706409
也就是你也可以随时可以跳到这个操作中回来

在这里插入图片描述

所以说你只要通过它，列出所有操作的 commit id ，然后找到自己的代码要到哪笔commit id
利用 commit id 就可以为所欲为，想代码跳到哪个 commit id 去就到哪个代码记录里面去

说一个额外的操作

git diff + 某个commit id 可以查看当前代码跟指定 commit id 的那时候代码的差异
你可以通过类似 git diff 8b650b353d01d17745c0700aa29ce9f9d14bf28c >> C:\Users\Desktop\diff.txt 这种操作，把所有差异放到这个创建的文本下，去查看

上面的第4点是，让你的代码回退历史记录的某一笔，如果说你想撤销历史记录中某一笔commit提交，你认为他写错了，执行

**git revert -n commitid **

-n 的目的是跳过文本编辑器
如果你直接执行 git revert commitid 界面会跳转到文本编辑器，他的意思是让你修改提交信息，也就是 revert 的工作是在原来代码上再添加一笔（回退某个commit）的 commit。而文本编辑器的意思就是让你写下这个新的 commit 的信息你要写啥，你可以按 ctrl x 选择离开，那么会使用默认的提交信息
也就是叫做 “Revert xxxxx”

一般情况下写下-n 就不让界面跳转到文本编辑器，直接使用默认提交信息即可，
如果你想修改下提交信息可以直接执行命令

git revert -m “xxx信息” commitid

注意，这个命令操作后，只是把指定的commit代码修改回退了，但是没有还没有生成一笔回退后的commit ，相当于代码回退了，但是你想要再生成一笔commit 就得自己写

android studio 中如果想回退掉某笔历史修改，可以在git 历史记录可见页面下点击右键然后选择Revert commit .这个时候就会再次生成一个新的commit 记录这个记录就是记录你这次回退操作，然后你就可以把这次回退操作这个commit ，根据需要是否git push 到远程分支，让远程分支也是否回退掉这笔操作

基础操作

git add 用于将工作区的修改行为放入暂存区

git commit 用于将暂存区提交修改分支下

git log 查看每个commit 信息。每个commit 都个独一的 id号。

git status 查看当前分支下，对比上一个commit 信息，当前分支的哪些文件被修改了

git diff 查看当前分支下，还没commit的项目里，文件被修改具体内容

切换查看创建分支，提交合并代码关联远程分支操作：

git branch 查看本地所有分支并且查看当前所在的分支

git branch -a 查看本地和远程所有分支

git branch test 从当前分支新建一个本地分支test

git checkout -b test 从当前分支新建一个本地分支test 并切换到test分支

git fetch **把远程所有的分支叫做 origin/xxx 都拉下来，创建对应的一个个引用

git fetch origin b 单独拉远程指定的b

git checkout xxx 切换本地所有分支下的 xxx分支

git checkout origin/xxx 切换一个本地分支叫 origin/xxx的分支

当你通过 git clone 命令从远程仓库克隆项目时，会在本地创建一个名为 origin 的远程仓库的副本
也是对于你本地来说，远程仓库默认名字就叫做 origin
origin代表远程仓库地址的一个简称
你可以理解为origin默认就是代表远程仓库

注意你可以在 origin/master 分支上进行开发，但是这不推荐

需要注意以下几点：

origin/master 是一个远程分支的本地快照，它不是一个可编辑的分支。任何在 origin/master 分支上的修改都会被视为不可推送的本地修改。

当你希望把你的本地master分支提交到远程的时候，

你不可以直接git pull 更新远程到本地，也不可以直接git push 推上去。
因为此时你本地的master 分支还没有跟远程的任何分支关联上去

你就是要获取远程的一个叫做 origin/master 分支的代码同步到本地当前分支 master 上

上面是手动每次提交拉取都要指明的操作
还有一种方式

你需要执行的时候添加 -u

git push -u origin master

-u 的作用就是一个让本地代码分支 master 跟远程仓库名为 origin（因为默认就是 origin）的一个叫做 origin/master 分支绑定在一起

git push -u origin master 跟 git push --set-upstream origin master 的作用是一样的

其实提交代码真正的原始写法应该是

git push 仓库地址对应要提交的分支名

可通过命令 git remote -v 查看当前的文件他是属于那个 git 仓库的，以及它git push 的仓库地址在哪里

不过，仓库地址可以用 origin 代替这个仓库地址

git push origin master 跟 git push origin/master 区别

git push origin master的意义是把本地一个master 提交到远程仓库一个叫做origin仓库的一个叫做 origin/master 分支上

而 git push origin/master 是会尝试将本地的 origin/master 分支推送到远程仓库，这通常是不推荐的操作。

本地的 origin/master 分支是远程仓库中的 origin/master 分支在本地的引用，它代表了远程仓库中的最新提交

git branch -u origin/doe

branch 代表当前分支，也就是你得checkout 到master 分支，才做上面的操作
-u 是绑定本地跟远程意义
origin/doe 是代表要跟远程的 origin/doe 进行绑定

或者执行
git branch --set-upstream-to=origin/doe
也是一样的效果

注意 git branch -u origin/doe 跟 git branch -u origin doe 还是不一样的

git branch -u origin/doe 是把本地当前的分支跟远程的一个叫做 origin/doe的分支绑定在一起

如果你想查看当前仓库对应的本地分支跟远程的哪个分支绑定在一起
可执行命令

git branch -vv

例如，如果你的当前分支是 master，并且它与远程分支 origin/master 关联，那么命令的输出可能类似于：

  master        abcd123 [origin/master] Commit message
  branch1       1234abc [origin/branch1] Another commit message
  branch2       5678def Some commit message

在这个示例中，master 分支与 origin/master 分支关联，branch1 分支与 origin/branch1 分支关联，而 branch2 分支没有关联的远程分支

merge 合并代码操作

如果你在合并其他分支过来你的分支时候，出现冲突而你不知道如何解决，不小心关了合并界面，这个时候当前分支卡在了合并当中。。报出 error: You have not concluded your merge (MERGE_HEAD exists).
你不想合并了想回原来的样子，这时候：输入命令 git merge --abort 去中止合并

当在 a 分支。 git merge b分支。就是把本地的b分支代码合到a分支上。

当在 a 分支想 merge 远程下最新的 b分支到目前的a 上来。

要么就是切到本地 b分支去pull 拉远程最新的 b 到本地的 b下来。然后在切到a去 merge b 进来。

要么就是在 a分支先执行 git fetch origin b 。这句话的意思就是远程最新的 b 会拷贝一份在本地上他叫做 origin/b 分支。他不同与你本地的b 分支。因为远程的跟你本地b不一定相同，而 origin/b 就肯定跟远程的b相同。执行完 git fetch origin b 就代表本地有了最新的远程b代码他在本地的 origin/b 分支，然后你再执行
git merge origin/b 就是把本地的 origin/b 的分支东西给当前的分支。
也就是执行 git fetch origin b 和 git merge origin/b 两个命令一起 实现效果就是把远程的b 给当前的分支

要么就是在a分支 git pull origin b

非常注意： git merge origin b

这句话代表的是把 2个分支合并到当前分支。

这里因为 origin后没写名字，所以他就默认指向本地的一个叫做 origin/master 分支的名字
然后把 origin/master分支和本地的 b分支合并到当前的分支。

merge 命令规矩就是把 merge 后面的 n个分支的名字合并到当前的分支。

对某个commit creat Patch。可以把这个commit 给生成一个patch 文件出来
然后再 Apply Patch 把指定的 Patch 合到对应的需要的代码上，
和进去的时候，打钩的文件代表要合入的，如果有的文件不需要合入，就取消打钩

合完在手动走正常流程 git add git commit git push 就行

删除分支操作

** ：

我现在在dev20181018分支上，想删除dev20181018分支

1 先切换到别的分支: git checkout dev20180927

2 有必要的情况下，删除远程分支(慎用)：git push origin --delete dev20181018

3 删除本地分支： git branch -d dev20181018

4 如果删除不了可以强制删除，git branch -D dev20181018

合入patch文件操作

1.准备好patch 文件，通常以 .patch 或 .diff 扩展名结尾

git apply xxx/xxx/xxx.patch

如果成功会看到成功提示，并且代码已经合入项目中，你需要 git add git commit git push 去提交

如果失败会有冲突则需要手动解决

git stash 之妙

**
git stash 可以把你当前还没git add 的草稿，也就是还在工作区的代码给保存下来，并且回退你的修改
当你还需要的时候，就可以执行 git stash pop 把刚的修改代码重新回来

有很多场景需要用到它

你在本地 A 分支做了你的修改，但是你还没有准备 add commit 这只是草稿，你不想commit 你的修改
这个时候，你想要切换本地B分支，但是切换本地B分支的时候由于在A 分支的修改导致切的是会冲突，这个时候你

在A的时候
git stash // 这个命令就把A的草稿保存下来
然后这个时候切换B就不会因为差异导致的冲突
然后回到A的时候再
git stash pop // 这个命令刚再A的修改草稿回退回来

注意，当你再执行
git branch -a 查看远程的分支。
然后 git reset --hard remotes/origin/master
让本地代码和远程分支保持一致前，看下手里的草稿代码是否需要保存
如果你需要保存，那么先需要 git stash 保存下来，

git stash 把草稿保存下来。
git reset --hard remotes/origin/master 然后在让本地代码和远程分支保持一致
最后让草稿回来 git stash pop

上面的 git stash 和 git stash pop 只是保存了一次工作区（草稿），那如果我想保存多个工作区（草稿）

有如下好用的命令可使用

git stash save “message”：保存当前工作目录的修改并添加一条说明信息。
git stash list：列出保存的 stash 记录。
git stash apply id数字：恢复指定的 stash 记录并保留 stash 记录。
git stash pop id数字：恢复指定的 stash 记录并删除 stash 记录。
git stash drop id数字 ：删除指定的 stash 记录。

打个比方，我下面需要保存3次草稿，对应上删除 MainActivity1 MainActivity2 MainActivity3的日志
在这里插入图片描述