TDZ
Temporal Dead Zone, TDZ
介绍一个样例
var x = 1;
function foo(x = x) {
console.log(x);
}
foo();
// Uncaught ReferenceError: x is not defined
以上可以转成为如下代码,便于理解:
var x = 1;
function foo() {
let x = x;
console.log(x);
}
foo();
我个人理解为,let 变量没有前置,导致执行到某一行,该行没有定义。
References
git 实践
背景
某同学在指定分支上做了修改,但是执行 fetch 的时候并没有认真看 fetch 后的提示(reject)。复盘的时候发现是该同学脑中认为自己本地没有该分支,git fetch 是不会有任何 reject 的可能性,因此并没有认真看 fetch 后的提示。(目前暂无办法解决不看 git 操作后的 message 的问题) 该同学是为了解决 PR 与 master 的冲突,但是不记得自己曾改过指定的分支,git fetch 完直接到指定的分支操作 git rebase master。
问题
- 有一个 dirty commit 并且已经合到了 master。
- 合到 master 的分支为了解决冲突使用了 git rebase。
图片由子龙提供,感谢子龙。
目标
- 尽可能让所有相同的 commit 只出现一次。
- 尽可能使用少的命令。
操作流程
- 复盘:重新回顾整个流程,看哪个步骤发生了问题,该如何解决。
git 操作
操作 1
$ git merge master # 在正确的分支下使用 git merge master。解决此时放生的所有冲突。(如果在这个时候直接使用 git rebase master,将需要面临很多次 commit 产生的冲突,产生冲突后直接用 git rebase --skip 可能会错过自己期望的代码)
$ git reset --soft HEAD~ # 保留最后修改的冲突代码。
$ git stash
$ git rebase master # 遇到冲突后直接 git rebase --skip(由于该分支下有多个 commit,因此需要执行多次 git rebase --skip)。
$ git stash pop
$ git add .
$ git ci -m 'Add: 添加修改'
操作 2
突然想到一个更简单的方式去处理。
$ git co master
$ git co -b <branch>
$ git cherry-pick <multiple commit> # 直接 cherry-pick 缺的 commit,可多个 commit。
最后解决问题。
Array Like
Array Like
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
<!DOCTYPE html>
<html>
<body>
<div id='testArrayLike'>
abc
</div>
<br />
<br />
<div id='mylog' style='color: red'>
</div>
<script>
var arg = 'log';
arg = 'assert'; // TODO:
var baseLogFunction = console[arg];
console[arg] = function(){
baseLogFunction.apply(console, arguments);
var args = Array.prototype.slice.call(arguments);
for(var i = 0; i < args.length; i++){
var node = createLogNode(args[i]);
document.querySelector("#mylog").appendChild(node);
}
}
function createLogNode(message){
var node = document.createElement("div");
var textNode = document.createTextNode(message);
node.appendChild(textNode);
return node;
}
window.onerror = function(message, url, linenumber) {
console[arg]("JavaScript error: " + message + " on line " +
linenumber + " for " + url);
}
/*
// Determine if o is an array-like object.
// Strings and functions have numeric length properties, but are
// excluded by the typeof test. In client-side JavaScript, DOM text
// nodes have a numeric length property, and may need to be excluded
// with an additional o.nodeType != 3 test.
function isArrayLike(o) {
if (o && // o is not null, undefined, etc.
typeof o === 'object' && // o is an object
isFinite(o.length) && // o.length is a finite number
o.length >= 0 && // o.length is non-negative
o.length===Math.floor(o.length) && // o.length is an integer
o.length < 4294967296) // o.length < 2^32
return true; // Then o is array-like
else
return false; // Otherwise it is not
}
*/
function isArrayLike(o) {
return o
&& typeof o === 'object'
&& isFinite(o.length)
&& o.length >= 0
&& o.length === Math.floor(o.length)
&& o.length < 4294967296; // 4294967296 means 2^32;
}
function testArguments () {
console.log(arguments, Array.isArray(arguments), arguments.length, Array.isArray(arguments[3]));
console.log('arguments', isArrayLike(arguments));
}
testArguments(2, 3, 4, [1, 2, 3]);
var a1 = {a: 1, b: 2, length: 4294967296};
var a2 = {a: 1, b: 2, length: Math.pow(2, 32)};
var a3 = {a: 1, b: 2, length: 1.1};
var a4 = {a: 1, b: 2, length: '3'};
var a5 = '123';
var a6 = {a: 1, b: 2, length: Infinity};
var a7 = {a: 1, b: 2, length: 30};
var isShowError = false;
isShowError = true; // TODO:
console.assert(isArrayLike(document.querySelector('#testArrayLike')) === isShowError, 'element testArrayLike', document.querySelector('#testArrayLike'));
console.assert(isArrayLike(document.querySelectorAll('#testArrayLike')), 'element all testArrayLike', document.querySelectorAll('#testArrayLike'));
console.assert(isArrayLike(a1) === isShowError, '4294967296 a1', a1);
console.assert(isArrayLike(a2) === isShowError, 'Math.pow(2, 32) a2', a2);
console.assert(isArrayLike(a3) === isShowError, 'a3', a3);
console.assert(isArrayLike(a4) === isShowError, 'a4', a4);
console.assert(isArrayLike(a5) === isShowError, 'a5 String', a5);
console.assert(isArrayLike(a6) === isShowError, 'a6', a6);
console.assert(isArrayLike(a7), 'a7', a7);
</script>
</body>
</html>
ES6(二)
箭头函数还有一个功能,就是可以很方便地改写λ演算。
// λ演算的写法
fix = λf.(λx.f(λv.x(x)(v)))(λx.f(λv.x(x)(v)))
// ES6的写法
var fix = f => (x => f(v => x(x)(v)))
(x => f(v => x(x)(v)));
函数绑定
foo::bar;
// 等同于
bar.bind(foo);
foo::bar(...arguments);
// 等同于
bar.apply(foo, arguments);
const hasOwnProperty = Object.prototype.hasOwnProperty;
function hasOwn(obj, key) {
return obj::hasOwnProperty(key);
}
尾调用
“尾调用优化”(Tail call optimization),即只保留内层函数的调用帧
尾递归
递归非常耗费内存,因为需要同时保存成千上百个调用帧,很容易发生“栈溢出”错误(stack overflow)。但对于尾递归来说,由于只存在一个调用帧,所以永远不会发生“栈溢出”错误。
function Fibonacci (n) {
if ( n <= 1 ) {return 1};
return Fibonacci(n - 1) + Fibonacci(n - 2);
}
Fibonacci(10); // 89
// Fibonacci(100)
// Fibonacci(500)
// 堆栈溢出了
改成
function Fibonacci2 (n , ac1 = 1 , ac2 = 1) {
if( n <= 1 ) {return ac2};
return Fibonacci2 (n - 1, ac2, ac1 + ac2);
}
Fibonacci2(100) // 573147844013817200000
Fibonacci2(1000) // 7.0330367711422765e+208
Fibonacci2(10000) // Infinity
即可。
重构(一)
第一步 写测试
好的测试是重构的根本。
代码块越小,代码的功能就愈容易管理。
这本书写于 1999 年。
好的代码应该清楚表达出自己的功能。
函数应该放在它所使用的数据的所属对象内。
减少临时变量,它没啥意义,至于性能代价,你应该在一个地方统一去处理。为此还可以多写一些循环,就是循环里面的临时变量也抽出来。
抽离代码,把相关性的放一起。
重构的节奏:测试、小修改、测试、小修改……
重构:对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。
重构改进软件设计、重构使软件更容易理解、重构帮助找到 bug、重构提高编程速度。
我不是个伟大的程序员,我只是个有着优秀习惯的好程序员。
重构应该是随时随地进行。
你之所以重构,是因为你想做别的什么事,而重构可以帮助你把这些事做好。
事不过三,三则重构。
结对编程重构,代码复审重构,一对一。
容易阅读、所有逻辑都只在唯一地点指定、新的改动不会危机现有行为、尽可能简单表达条件语句。
重写代码比重构简单的时候可以考虑就重写了。现有代码各种 bug,那就更可以重写了。
重构可以提高生产力的。
事先设计足够合理的方案,然后慢慢重构。
坏味道:duplicated code 1. 同一个类的两个函数含有相同的表达式。2. 两个互为兄弟的子类内含相同表达式。
说明写进一个独立函数种,以用途命名。关键在于函数做什么,如何做。
讲总是一起变化的东西放在一块儿。
当你觉得需要撰写注释时,请先尝试重构,试着让所有注释都变得多余。注释可以用来记述将来的打算,标记你并无十足的把握,还可以记录为什么做某事。
测试是可以提高开发效率的。
一套测试就是一个强大的 bug 侦测器,能够大大缩减查找 bug 所需要的时间。
用单元测试来暴露 bug。
测试你最担心出错的部分,这样你就能从测试工作中得到最大的利益。
编写未臻完善的测试并实际运行,好过对完美测试的无尽等待。
边界条件的测试,对 read 而言是第一个字符、最后一个字符和倒数第二个字符。
花合理时间抓出大多数 bug 好过穷尽一生抓出所有 bug。
重构列表: 重构词汇表,简短概要,动机,做法,范例。
Review
岁月如梭。
第二季度读的书并不多,很多书也并没有读完。
《鱼羊野史(1-4)册》只读了一半。 《How Google works》只读了 89%。
《小王子》 | 46分 | 36687字 |
《西游日记》 | 3时12分 | 101847字 |
《悟空传》 | 4时44分 | 132049字 |
《霍比特人》 | 4时36分 | 180808字 |
### 继续 Review。
- 软素质有所提升,敢去交流,敢去玩欢乐谷的恐怖的云霄飞车。
- 继续缺钱。
- 一直在健身。Keep 的记录:累计训练 21 天,完成训练 27 次,累计消耗 4227 千卡,连续训练最大时间为 12 天。
- 参加了公司舞蹈兴趣小组,去上课了,但是仍缺乏课后训练。
- 看了书,还需要看更多。
- 对旅游不太感兴趣,对旅游的理解是旅游就是为了放松,如果我只家就挺放松的,可以在家;如果需要出行去海边才能放松,那就去海边,去晒太阳。
任重道远。
to be continue…
why post data choose json not form
JSON 传输是带类型的,你说的传统的POST是Content-Type:application/x-www-form-urlencoded,就表示虽然也按键/值传递了,但确实字符串,本来数据该有的类型被忽略了。 JSON 类型的数据可以比较好的支持嵌套的数据格式,这种数据格式在后端可以和文档数据库(比如 mongodb)的存储结构直接对应;在前端可以和 js 的数据对象直接对应。 https://segmentfault.com/q/1010000003015987
浏览器中的 key=value&key=value 是拼接在 url 上然后传递给 server 的,别说用的是POST 请求,其实和 GET 没啥区别。虽然都能解决问题,但有优劣之分。 1.用 KV 连接 URL,使得 URL 比较丑陋。 2.用 KV 连接 URL,如果有敏感信息,存在安全问题。 3.用 KV 连接 URL,长度有限制。 如果用 JSON,可以使用 request body 发送数据,就回避了第一点第三点,第二点相对来说要好点。 JSON 格式的数据现在比较通用,各种语言支持性都比较好。
四种常见的 POST 提交数据方式 https://imququ.com/post/four-ways-to-post-data-in-http.html
Git 回到未来
git rebase
修改 commit 的顺序、内容,修改历史。
$ git rebase -i HEAD~5
pick 3d60303 Update content ponctuation$
pick 17aa86b Add copywriter style and update about.$
pick 27729ba Update style guide$
pick 3f90bbf Update css and about$
pick 86a43d2 add draft$
$
# Rebase b2811ee..86a43d2 onto b2811ee (5 command(s))$
#$
# Commands:$
# p, pick = use commit$
# r, reword = use commit, but edit the commit message$
# e, edit = use commit, but stop for amending$
# s, squash = use commit, but meld into previous commit$
# f, fixup = like "squash", but discard this commit's log message$
# x, exec = run command (the rest of the line) using shell$
# d, drop = remove commit$
#$
# These lines can be re-ordered; they are executed from top to bottom.$
#$
# If you remove a line here THAT COMMIT WILL BE LOST.$
#$
22 # However, if you remove everything, the rebase will be aborted.$
#$
# Note that empty commits are commented out$
$ git rebase -i <commit>
这个命令就是列出到指定 commit 的所有 commit,然后我们可以对这些 commit 进行操作,比如说删掉某几个 commit、合并某几个、调换某几个 commit 的顺序。
原本我们的 git flow 是:
$ git log --oneline --graph --decorate --all
* ed4c919 add draft
* f105e3d Merge pull request #11 from lincolnge/release
|\
| * 3f90bbf Update css and about
|/
* 27729ba Update style guide
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
执行 $ git rebase -i HEAD~5
,没有进行任何操作,就退出,执行 $ git log --oneline --graph --decorate --all
可以看到,现在我们的 git flow 是:
* f423ed9 (HEAD -> test) add draft
| * 79bdd26 (origin/master, origin/HEAD, master) add post git back to the future
| * ed4c919 add draft
| * f105e3d Merge pull request #11 from lincolnge/release
| |\
| |/
|/|
* | 3f90bbf Update css and about
|/
* 27729ba Update style guide
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
我们可以认为 git rebase
操作把我们的 commit 给捋平了。就是当前 branch 的分支变成这样了。($ git log --oneline --graph --decorate
,去掉远程的 git flow,可以看得更清晰一些。)
* f423ed9 (HEAD -> test) add draft
* 3f90bbf Update css and about
* 27729ba Update style guide
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
原本那个 merge 操作产生的 commit 被删掉了。
这里可以插一段,解决冲突。当我们发完 PR 的时候,产生冲突了,这个时候要在本地解决这个冲突,我们可以使用 git rebase 或 git merge 去解决冲突,区别就是 git merge 会多产生一个 commit,然后使用 git rebase 会更改你这个 PR 里 所有 commit 的 hash 值。然后当你发现你解决冲突的时所做的操作有问题时,git merge 更容易进行回溯的操作,直接 git reset 即可。
# Commands:$
# p, pick = use commit$
# r, reword = use commit, but edit the commit message$
# e, edit = use commit, but stop for amending$
# s, squash = use commit, but meld into previous commit$
# f, fixup = like "squash", but discard this commit's log message$
# x, exec = run command (the rest of the line) using shell$
# d, drop = remove commit$
看看我们的 rebase -i 里面的有的操作。默认都是 pick。
pick 3d60303 Update content ponctuation$
pick 17aa86b Add copywriter style and update about.$
pick 27729ba Update style guide$
pick 3f90bbf Update css and about$
pick 86a43d2 add draft$
比如把第二个 pick 改成 r,
pick 3d60303 Update content ponctuation$
r 17aa86b Add copywriter style and update about.$
pick 27729ba Update style guide$
pick 3f90bbf Update css and about$
pick 86a43d2 add draft$
保存并退出,发现我们到了 Add copywriter style and update about.
这个状态的时间点。我们可以对这个 commit 的 comment 进行操作,更改这个 commit comment。
NORMAL ▶▶ .git/rebase-merge/git-rebase-todo[+] ◀ gitrebase ◀ utf-8[unix] ◀ 8% ¶ 2: 2 ◀
".git/rebase-merge/git-rebase-todo" 24L, 842C [w]
Rebasing (2/5)
Add copywriter style and update about, change cimmit comment.$
$
# Please enter the commit message for your changes. Lines starting$
# with '#' will be ignored, and an empty message aborts the commit.$
#$
# Author: lincolnge <326684793@qq.com>$
# Date: Sat May 21 22:06:21 2016 +0800$
#$
# interactive rebase in progress; onto b2811ee$
# Last commands done (2 commands done):$
# pick 3d60303 Update content ponctuation$
# r e18bd53 Add copywriter style and update about, change cimmit comment.$
# Next commands to do (3 remaining commands):$
# pick e256546 Update style guide$
# pick 69c9c89 Update css and about$
# You are currently editing a commit while rebasing branch 'test' on 'b2811ee'.$
#$
# Changes to be committed:$
#»——————new file: _posts/2016-05-21-copywriting-style-guid.md$
#»——————modified: about.md$
#$
对 commit comment 修改并保存,保存完后,发现我们又重新回到了现在。重新执行 $ git log --oneline --graph --decorate
,我们会看到我们的 commit comment 变了:
* 5c952ba (HEAD -> test) add draft
* 0a8c12c Update css and about
* 2dc468e Update style guide
* 8f265f0 Add copywriter style and update about, change cimmit comment.
* 3d60303 Update content ponctuation
这就是我们对过去进行了矫正,然后影响了我们的未来。
# r, reword = use commit, but edit the commit message$
# e, edit = use commit, but stop for amending$
# s, squash = use commit, but meld into previous commit$
# f, fixup = like "squash", but discard this commit's log message$
# x, exec = run command (the rest of the line) using shell$
# d, drop = remove commit$
看一下我们剩下的还有什么命令,edit、squash、fixup、exec、drop。顾名思义,edit 就是回到我们过去的那个时间点,然后对当时的 commit 进行修改,你可以直接在那个 commit 时间下添加新的 commit 或者你做你想做的任何一件事,结束后就执行 git rebase --continue
回到未来。
在 edit 状态下,我们同样可以执行 git rebase --edit-todo
看未来的 commit 或者对未来的 commit 执行类似 edit、squash、fixup、exec、drop 操作。
- squash 就是把指定的 commit 与它之前的 commit 合并,比如说你写了很多 fix bug、fix bug 的 commit,可以用这个 squash 统一变成一个 commit。
- fixup 与 squash 类似,但是它放弃了自己的部分权利,就是修改 commit comment 的信息。直接就合到它之前的 commit 了。
- drop 放弃这个 commit
- exec 也是一个很有趣的命令,它能让你到某个过去,然后执行指定的命令。
如下:
pick 3d60303 Update content ponctuation$
exec npm run test
pick 17aa86b Add copywriter style and update about.$
exec npm run test
pick 27729ba Update style guide$
exec npm run test
pick 3f90bbf Update css and about$
exec npm run test
pick 86a43d2 add draft$
友情提示,我们在解决冲突的时候有个命令叫 $ git rebase --skip
,可以认为是去掉冲突的代码,也就是和遵从 git rebase
git cherry-pick
这个命令相对于 git rebase 来说,简单得多了,它就是把某个 commit 提取出来,放置到当前 branch 的 HEAD 上。
$ git cherry-pick 27729ba 17aa86b 3d60303 b2811ee f891ff0 7d3e6ae 7256dc9 30cb9d5 d9c90e4
[test 1de481e] Update style guide
Author: lincolnge <326684793@qq.com>
Date: Sat May 21 22:07:37 2016 +0800
1 file changed, 4 insertions(+)
[test a5b1c9b] Add copywriter style and update about.
Author: lincolnge <326684793@qq.com>
Date: Sat May 21 22:06:21 2016 +0800
2 files changed, 23 insertions(+), 2 deletions(-)
create mode 100644 _posts/2016-05-21-copywriting-style-guid.md
error: could not apply 3d60303... Update content ponctuation
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
遇到冲突(conflict),
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
这三句就是冲突的意思了。解决一下冲突,然后执行 $ git cherry-pick --continue
,不像 git rebase,git cherry-pick 没有 –skip 方法。和 rebase 一样可以执行 git cherry-pick --abort
终止命令。
拓展与 git rebase & git merge 的联合使用。
我们可以测试一下当我们 cherry-pick 某个分支的某个 commit 之后,重新去合对应的分支,是否会产生冲突。
$ git co -b test2
$ git log --oneline --graph --decorate
* ed4c919 (HEAD -> test, master) add draft
* f105e3d Merge pull request #11 from lincolnge/release
|\
| * 3f90bbf Update css and about
|/
* 27729ba Update style guide
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
看到我们的树状结构是这样的。
$ git reset --hard HEAD~3
HEAD is now at 17aa86b Add copywriter style and update about.
$ git log --oneline --graph --decorate
* 17aa86b (HEAD -> test) Add copywriter style and update about.
* 3d60303 Update content ponctuation
* b2811ee Update post content
* f891ff0 Update post title
* 7d3e6ae Update post title
$ git cherry-pick ed4c919
[test eeadbc2] add draft
Author: wanggengzhou <326684793@qq.com>
Date: Sat Oct 3 15:01:24 2015 0800
3 files changed, 978 insertions()
create mode 100644 _posts/2015-06-09-web.md
create mode 100644 _posts/reading/2015-06-24-the-art-of-speak.md
create mode 100644 _posts/reading/2015-08-23-tan-xiu-yang.md
$ git log --oneline --graph --decorate
* eeadbc2 (HEAD -> test) add draft
| * ed4c919 (master) add draft
| * f105e3d Merge pull request #11 from lincolnge/release
| |\
| | * 3f90bbf Update css and about
| |/
| * 27729ba Update style guide
|/
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
看到我们这个时候的状态,我们可以选择 git merge 或 git rebase master 分支。
$ git co -b test2
checkout 一个新的分支,test 用来执行 git rebase,test2 用来执行 git merge。
$ git merge master
* 395d3bd (HEAD -> test2) Merge branch 'master' into test2
|\
| * ed4c919 (master) add draft
| * f105e3d Merge pull request #11 from lincolnge/release
| |\
| | * 3f90bbf Update css and about
| |/
| * 27729ba Update style guide
* | eeadbc2 (test) add draft
|/
* 17aa86b Add copywriter style and update about.
$ git rebase master
* ed4c919 (HEAD -> test, master) add draft
* f105e3d Merge pull request #11 from lincolnge/release
|\
| * 3f90bbf Update css and about
|/
* 27729ba Update style guide
* 17aa86b Add copywriter style and update about.
* 3d60303 Update content ponctuation
* b2811ee Update post content
我们可以发现执行完 rebase 得到的结果,与 master 的结果是一样的。结论:rebase 是个神奇的命令。使用 cherry-pick 不会产生的冲突。
git filter-branch
git filter-branch
这个命令非常强大,可以批量改写历史,当前 branch 中所有的 commit 的历史或者所有分支,可以选择适用的范围。
批量删除指定的 filename 文件:
$ git filter-branch --tree-filter 'rm -f filename' -- --all
例如:
$ git filter-branch --tree-filter 'rm -f test' -- --all
Cannot rewrite branches: You have unstaged changes.
当然不能有修改,可以先执行 $ git stash
命令。
$ git filter-branch --tree-filter 'rm -f test' -- --all
Cannot create a new backup.
A previous backup already exists in refs/original/
Force overwriting the backup with -f
出现这一句说明之前曾经执行过 git filter-branch,然后在 refs/original/ 有一个备份,这个时候只要删掉那个备份即可,删除备份命令为 git update-ref -d refs/original/refs/heads/master
,或执行 $ git filter-branch -f --tree-filter -f 'rm -f test' -- --all
。
为了避免因操作错误造 repo 损坏,git 会在 filter-branch 操作实际改写历史时,自动将原 refs 备份到 refs/original/ 下。
$ git filter-branch -f --tree-filter 'rm -f test' -- --all
Rewrite 283f0899973f574fd879f565b69da2705dc3ede7 (406/412) (24 seconds passed, remaining 0 predicted)
WARNING: Ref 'refs/heads/master' is unchanged
WARNING: Ref 'refs/heads/release' is unchanged
Ref 'refs/heads/test' was rewritten
Ref 'refs/heads/test2' was rewritten
Ref 'refs/heads/test3' was rewritten
Ref 'refs/heads/test4' was rewritten
Ref 'refs/heads/test5' was rewritten
Ref 'refs/heads/test6' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
WARNING: Ref 'refs/remotes/origin/master' is unchanged
WARNING: Ref 'refs/remotes/origin/release' is unchanged
WARNING: Ref 'refs/stash' is unchanged
看看改了什么 $ git status
:
$ git st
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working directory clean
看看 .git/refs/original/
里有啥:
$ l .git/refs/original/refs/heads/
total 24K
drwxr-xr-x 8 wanggengzhou staff 272 May 30 00:12 ./
drwxr-xr-x 3 wanggengzhou staff 102 May 30 00:09 ../
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:11 test
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:11 test2
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:11 test3
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:11 test4
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:12 test5
-rw-r--r-- 1 wanggengzhou staff 41 May 30 00:12 test6
$ cat .git/refs/original/refs/heads/test
a1029f5cce896f6d65dfbc5edfcf3487459aad3b
refs/original/
里保存的就是 hash 值。其他命令介绍。
更改历史提交中某一提交者的姓名及邮件地址。
$ git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "WangGengZhou" ]; then
GIT_AUTHOR_NAME="lincolnge"
GIT_AUTHOR_EMAIL="326684793@qq.com"
fi
git commit-tree "$@";
' HEAD
Reference:
- Git Documentation. https://git-scm.com/docs/git-rebase
- Git Documentation. https://git-scm.com/docs/git-cherry-pick
- Git Documentation. https://git-scm.com/docs/git-filter-branch
- GotGit. http://www.worldhello.net/gotgit/06-migrate/050-git-to-git.html
- loveky的一亩三分地. http://loveky2012.blogspot.com/2012/08/git-command-git-filter-branch.html
书写规范
http://open.leancloud.cn/copywriting-style-guide.html
中文、英文、数字混合时空格的使用
英文与非标点的中文之间需要有一个空格,如「使用 LeanCloud 开发移动应用」而不是「使用LeanCloud开发移动应用」。1 数字与非标点的中文之间需要有一个空格,如「我们发布了 5 个产品」而不是「我们发布了5个产品」。 尽可能使用中文数词,特别是当前后都是中文时。上面的例子写为「我们发布了五个产品」会更好。 数字与单位之间需要有一个空格,如「5 GB」而不是「5GB」。 注意特殊名词的大小写:Android、iOS、iPhone、Google、Apple,无论是否在句首都应该以同样的方式写。 在官方文案中尽量使用中文,避免中英文混合的情况。例如「app」一般应写为「应用」或「移动应用」。品牌、产品名、人名、地名等特殊名词,如果来自英文,请使用英文以避免在不同译法间选择。
每日三省吾身,早上吃什么,中午吃什么,晚上吃什么
写了那么多语言了,面向对象和结构化编程都理解了吗?各种语言的面向对象的继承有什么不一样呢?
像 JavaScript 有 4 种继承方式,各有千秋,那可有什么适用环境吗?
写代码没有用面向对象的特性,是因为没有对象吗?
有本书就挺有用的了,叫《重构》,看了吗,这是讲什么的呢?
语言间有什么优缺点,这个语言适合解决什么样的问题?
其实博客,如果数据量达到几千万,甚至上亿,那这个项目就是大项目了。怎么做优化呢,怎么才能承担这样的负载呢?
什么 Spark,React Native,都是解决什么问题呢?
vue 和 AngularJS 是异曲同工的,分别解决什么问题呢?
Weex 还是 HTML5,并不是 Native,那么在性能上,是否可以和真的 Native 比较呢?
React Native 主要是为了解决什么问题呢?(多端用同一套代码)Weex 主要是解决什么问题呢?
你学习某个技术可以让你增加你对技术深度上的理解吗?
学那么多东西,可是本质的东西都没有学,都没有深入,会不会让大家觉得自己浅尝辄止,遇到困难就退缩呢?
运维需要自动化部署,Shell 命令都熟悉了吗?
遇到服务器崩溃,怎么解决呢?
未完待续…
学一个技术,没有学到精通的话,其实是没有什么意义的,要达到半吊子太容易了,我看本书,花几天,我就能学会一种语言啦。精通:熟练掌握源码,掌握知识体系和生态环境。对相关技术发展有前瞻性认识,能够颠覆或者引领发展潮流。
严老师说:最近的理解是,简单的去写 Node、PHP、Java 并没有真的好处。另外前端方面,好的系统 ,如果用Backbone 写的,并不需要改成 React。前一段时间,本来想写一本集大成的文章,后来内容越来越多,再后来,写不下去了,思维越来越混乱,但是先把东西发表了出来。很多地方有错别字,还有语病,组织上也不好,要等我再想清楚以后,重新整理一篇。前端这一块儿,因为”不教真的“。市面上那些老师,自己都没有学到真谛,他们讲的话自然也不能算真东西。追本溯源我觉得要从优秀的后端那边学。优秀的后端其实比较多,找好的架构师跟着学。