Fake it until you make it

也许世界杯只是一面镜子，照出的是当下人们所要面对的信息环境。

这是收到的一条推送信息。原本并不打算写什么，习惯了睁一只眼闭一只眼的姿态，心知肚明便好。大概最近重温了《冰菓》的缘故，因而也想呐喊一声(冰菓= ice cream ≈ i scream)。

还拿世界杯来说。无论你看球与否，你多少还是能听到或看到这样的讯息:

日常 10 分钟提升记忆力和创造力

翻译自：This 10-Minute Routine Will Increase Your Memory And Creativity

当你训练你的创造力时，你会潜在地训练你的记忆力。当你训练你的记忆时，你会潜在地训练你的创造性思维!

托尼 · 布詹

记忆和想象是密不可分的。事实上，你的记忆是想象出来的。它既不具体也不客观。相反，你的记忆是你如何去存储、连接并解释一个人、地方或事物。

随着你的想象力越来越丰富，你的记忆力也会越来越好。很少有人学会如何利用自己的长期记忆。因为大部分人的记忆策略很差，使得他们学习效率低下，缺乏创造力，对自己缺乏信心。

如果你不记得某件事，那意味着你并没有学会它。

字前：今天我们要讨论的是开心的事。

几个小时以前。

是的，又开始下雨了。

也就是突然间那么一下，整个人莫名就陷入失落的怪圈。宛如好容易堆积起来的扑克楼，倏地就呼啦啦坍塌在你面前。究其原因，大概是体内累积的各种负面情绪伴随着雨水突然发作罢。雨势渐弱，失落感并未散去，反倒藉着周遭的霓虹愈演愈烈，人也开始变得焦躁，最终的结果是我生气了。于是索性漫步在街头，雨并没有下大的意思，所以心情也逐渐缓和。

回过头来，细想生气的缘由。雨天吗，还是因为堵车？答案是否定的，我并不特别讨厌堵车的下雨天。就算讨厌，也不到生气的程度。讨厌的大概是望着窗外时间随雨水流逝，脚底却并未挪动半步的无力感。出于牢骚，便向臭味相投的友人团吐了几句，因为我觉得他们肯定会站出来爱护我的。的确，他们真的站出来了，只不过最后的结论是我爱护他们胜过自己。

然而，关注点并不在于这个结论(因为这并不意外)，而在于其实每个人并没有你看到的那样开心。我想绝大多数人并不愿意把自己认为不好的一面展现在他人面前，即便是至亲：另一半甚至父母。并不是说虚伪，大概如同人生而孤独一般，下意识地自我保护在作祟罢了。

• Git 概念先行
  1. 工作区、暂存区和版本库
• Git 正常操作
  1. 配置 Git
  2. 创建版本库
  3. 基本玩法
  4. 撤销
  5. 远程仓库
  6. 打标签
  7. git别名

在任何一个阶段，都有可能想要撤消某些操作。方法的选择取决你的情况：是否已提交。如果是，你又想如何修复。

未提交

重置工作区

日常开发中，你可能会遇到工作区的文件搞的一团乱麻，这时你会想回到之前的状态：编辑前的干净状态，上次暂存的状态，上次储藏队列的状态。

干净状态

所谓的干净状态即最近一次提交时的状态。本质上是将版本库中版本恢复到工作区和暂存区中。即重置。

到了这里相信你的机器上已经有了一个 Git 仓库，并且工作区里也签出了工作副本。通常，当项目达到想要记录的状态时，我们开始对文件进行更改并将这些变更的快照提交到存储库中。

工作目录里的文件无非两种状态：已追踪或者未追踪。已追踪文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录;它们可以是「未修改」、「已修改」、「已暂存（staged）」。简而言之，追踪的文件就是 Git 所知道的文件。

工作目录中除已追踪文件以外的所有其它文件都属于未追踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已追踪文件，并处于未修改状态。

编辑过工作区的某些文件之后，由于自上次提交后对它们做了修改，Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区(add)，然后提交所有暂存了的修改(commit)，如此反复。所以使用 Git 时文件的生命周期大致如下：

Git 目录

创建了版本库后。首先，让我们来看一看 Git 仓库的目录结构。作为演示，我们初始化了一个叫做 project 的 Git 仓库。使用tree查看项目结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ cd C:/Hexo/gitpost/project
$ tree  -C -F -a -L 2
.
|-- .git/                   # 隐藏文件夹（**git版本库**）
|   |-- COMMIT_EDITMSG      #
|   |-- HEAD                # 这个git项目当前处在哪个分支里
|   |-- config              # 项目的配置信息，git config命令会改动它（仓库级别）
|   |-- description         # 项目的描述信息
|   |-- hooks/              # 系统默认钩子脚本目录
|   |-- index               # 索引文件（**暂存区**）
|   |-- info/               #
|   |-- logs/               # 各个refs的历史信息
|   |-- objects/            # Git本地仓库的所有对象 (commits, trees, blobs, tags)
|   `-- refs/               # 标识项目里的每个分支指向了哪个提交(commit)
`-- readme.md               # 项目文件（**工作区**）

既然我们现在把一切都设置好了，那么我们需要一个 Git 仓库。有两种方法可以得到它：

• 使用git init将现有的本地非版本控制目录转换成 Git 仓库
• 使用git clone从别处拷贝已存在的 Git 仓库

现有目录中初始化 Git 仓库

• 如果你需要对现存的未版本控制化的项目进行版本控制，你可以通过如下命令：

  1 2 3

  //项目所在根目录 $ cd <path/to/project> $ git init

Git 的配置文件

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置，针对三个级别System,User和Repository：

1. /etc/gitconfig 文件(一般是 Git 的安装目录): 包含系统上每一个用户及他们仓库的通用配置。 如果使用带有 --system 选项的 git config 时，它会从此文件读写配置变量。

2. ~/.gitconfig 或 ~/.config/git/config 文件(当前用户主目录)：只针对当前用户。 可以传递 --global 选项让 Git 读写此文件。

3. 当前使用仓库的 Git 目录中的 config 文件（就是 .git/config）：针对该仓库。

你可以通过git config -l --show-origin来查看当前目录下的 git 配置信息(配置来源+配置)：