初始状态


比如我们编辑 git 仓库内的 README.md,并将其 add to stage

这时候仓库状态

然后我们再对 README.md 进行修改

再来查看仓库状态

出现了同一文件同时处于 staged 和 modified 状态(接下来的操作全部都是从这个状态作为初始状态的进行测试的)

用这个状态依次试试 add/checkedout/commit/commit -a 这个文件,并查看文件和仓库状态

操作


add

先看 shell 的提示符:git:master o,说明当前仓库已经 clean 了,使用 status 命令查看也证实了这一说法

查看文件发现是第二次 modify 的版本(> Test ref)

可以推断在 add 了 unmodified 内容至 staged(覆盖原有 staged 内容) 之后自动地将 staged 内容提交了

但是这样就有一个问题,我们并没有为这次 commit 添加任何信息,让我们再来看看 git log,下面是最新的一次提交信息

看时间明显不是我这次 add 造成的自动 commit 的 log(上面 shell 中有显示当前系统时间)

那是不是可以视为这次提交的 log 丢失了呢?有知道具体原因的可以在评论区告诉博主

checkout

可以看到 unmodified 的文件已经消失了

再查看一下文件内容,发现变回了### Test h3

checkout 完全地撤销了 README.md 的这次 modify

commit

可以看到暂存区中的内容已经被提交了(有一个 deletion 的原因是我 REAME.md 文件中本来就有一行数据,被我 echo 命令给覆盖了),而 modified 文件依旧

再查看一下文件内容,发现还是> Test ref(已经 commit 的那个版本中是### Test h3,因此当前仓库还是处于 not clean 状态

commit -a

可以看到这次提交失败了

有意思的是提示当前仓库是 clean 的,但我们查看仓库状态发现当前状态和执行这条失败的 commit 前是一样的,这应该是一个 bug

不出意外,文件是第二次 modify 的内容(> Test ref)

### 总结

总而言之,为了方便管理和避免不必要的麻烦,我们自己在进行操作的时候应该尽量避免这种状态

但是无意进入这种状态之后:

  • 尽量选择 commit 操作把当前 staged 内容处理之后,再去处理 unmodified 内容

  • 如果第二次 modify 的内容不重要的话也可以直接 checkout 这次 modify,但是不推荐

  • 特别不推荐的就是在这种情况下使用 add,我在测试中就出现了无 log 提交的情况,如果第一次 modify 的内容很重要的话就很麻烦了

以上

问题描述


Oracle 版本 : 11g express
Oracle 服务器系统 : Windows Server 2008

今天在看 Oracle 的 PL/SQL 程序设计基础的时候,看书的过程中感觉 Oracle 确实和其他小型的数据库比起来在 PL/SQL 的设计上下了很大功夫

看完书了准备练几个老师给的实验…然而,第一个就卡住了

继续阅读