这才是真正的Git——Git实用技巧 - 网站源码_资源分享

译者：lzaneli，百度 TEG 前端合作开发技师

本系列产品通过两篇该文来详尽如是说译者的 Git采用心得体会。

前两篇该文见：

百度控制技术工程建设：这才是或者说的Git——Git外部基本原理详解！3706 赞成 · 69 评论该文

这是该系列产品的最终一则该文，以后的该文主要讲的是此基础基本原理部份，在认知基本原理的此基础上，如是说许多新颖的基本功给我们，期望能提升我们的合作开发工作效率。

这篇该文因为更多的是列出前述应用领域的基本功，因此该文内部结构会变得杂乱许多，也不能像前两篇该文那般明确要求我们次序写作。每一点都是相互分立的，我们能根据他们的需要自学。

在这篇该文里就要采用操作形式录屏的形式来如是说范例，期望这种形式能让你更简单的介绍指示的采用方式。

将两个commit组合成一个

⚠️ 这儿有一点要当心的是：rebase会引致捷伊commit结点造成，因此当心千万别对多人相连接的控制台组成部份进行rebase。

rebase -i 是个很新颖且应用领域广为的辅助工具，期望我们都专业委员会它的采用。它还能用以修正commit重要信息，舍弃这类commit，对commit进行次序之类。具体内容指示如下表所示，操作形式形式跟动图完全一致，都是在vim里头进行撰稿。这儿不进行，钟爱的老师能他们操作形式呵呵。

# Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like “squash”, but discard this commits log message # x, exec <command> = run command (the rest of the line) using shell # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commits # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message.

另外如果要合并的是最近的两个commit，我们还能用git reset –soft HEAD~3 && git commit -m xxx来实现。对这个有问题的老师能参照Git外部基本原理强调的可视化方式思考呵呵。

找回丢失的commit结点或组成部份

像上一步rebase后发现不符合预期，如何恢复？不小心删除了一个组成部份，如何找回？

“专业委员会这个技能，你的同事会请你喝奶茶的，而且说不定还能收获妹子。” —— 来自往期课程的某位老师

主要思路为：找到要返回的commit object的哈希值，然后执行git reset恢复。

我们知道Git的出现就是为了尽量保证我们的操作形式不被丢失，在Git外部基本原理中我们讲过，git object是旦被创建，就不可变更，因此只要找到它对应的哈希值，就能找回。但是ref呢？在Git内部基本原理中我们也讲过，它是一个可变的指针，比如说你在master中提交了一个commit，那当前的master这个ref就会指向捷伊commit object的哈希值。reflog 就是将这些可变指针的历史给记录下来，能认知成 ref的log，也能认知成版本控制的版本控制。

获得一个干净的工作空间

当我们实验一种思路，或者跟朋友讲代码时，我们可能会随意的修正代码。而当我们回到正常的合作开发时，我们需要一个干净的工作目录，即保证目前工作目录跟Git最终一次commit的文件是完全一致的。我们能怎么做？

尽量少用会丢失文件的操作形式，除非你能够确定不再需要这些文件。

修正最近一个commit

commit完发现有许多临时的log忘记去掉？有许多文件忘记添加？commit重要信息出现错别字？

也能采用 git reset HEAD~，然后执行你需要的修正，再commit即可，同上面如是说的指示效果是相同的。

提交一个文件中的部份修正

Git interactive add 还有很多功能，也推荐我们有时间能尝试呵呵。

禁止修正多人相连接的控制台组成部份

如果一条控制台组成部份有多人相连接，那么千万别在上面执行reset、rebase等会修改这条组成部份已经存在的commit object的指示。

具体内容的解释参照这篇该文 Rebase and the golden rule explained 。

撤销一个合并

如果是一个本地组成部份，仅需git reset –hard <合并前的SHA1>即可。

如果这个组成部份已经被推送到控制台，比如说合并进master，发到线上才发现有bug需要回滚。这时组成部份有可能已经被其他人所采用，根据“禁止修正多人相连接的控制台组成部份”，你需要执行git revert -m 1 <合并的SHA1>，新增一个revert结点，如下表所示图中的E。

但要注意千万别在原特性组成部份继续合作开发，而应该删除原来的组成部份，从E结点拉出新组成部份做bug修复等。

如果在原特性组成部份上继续合作开发，则在合并回master的时候需要做一次revert操作形式revert掉E结点，变成E‘’（如下表所示图），不然很容易出现丢失文件等问题。具体内容原因分析参照组成部份合并中的总结

从整个历史中删除一个文件

代码要开源了，但发现其中包括密钥文件或内网ip怎么办？

git filter-branch –tree-filter rm -f passwords.txt HEAD

能采用filter-branch指示，它的实现基本原理是将每一commit checkout出来，然后执行你给它的指示，像上面的rm -f passwords.txt，然后重新commit回去。

⚠️ 这个操作形式属于高危操作形式，会修正历史变更记录链，造成全捷伊commit object。因此执行前请通知仓库的所有合作开发者，执行后所有合作开发者从捷伊组成部份继续合作开发，弃用以前的所有组成部份。

其他好用的指示

下面这些指示也是比较新颖的指示，钟爱的同学能他们自学呵呵。

git bisect 二分查找出现问题的变更结点，比如你发现当前提前下测试是不通过的，但HEAD～10（10个提交前）的测试是能通过的，就能用git bisect 来帮你定位到出现问题的变更点。git blame 查看某行代码最终是谁修正的。git show-branch 简单的展示多条组成部份间的关系。git subtree 拆分或合并仓库。

期望我们读完有所收获。钟爱的老师能写作同系列产品的其他该文：

这才是或者说的Git——Git外部基本原理这才是或者说的Git——组成部份合并

参考

书籍 Scott Chacon, Ben Straub – Pro Git-Apress (2014) 书籍Jon Loeliger, Matthew McCullough – Version Control with Git, 2nd Edition – O’Reilly Media (2012)

Rebase and the golden rule explained