版本控制-git-东哥笔记

git文档

本文来源于labuladong的算法笔记

三个分区:working directory，stage/index area，commit history。

基本操作

查询当前HEAD状态

1

git status

强制修改分支指向

1

git branch -f xxx zzz

xxx是分支名，zzz是提交hash或者其他分支名

强制push：

1

git push orign main -f

需求一，如何把 work dir 中的修改加入 stage。

1

git add xxx

风险等级：无风险。

理由：不会改变任或撤销任何已作出的修改，而且还会将 work dir 中未追踪的修改（Untracked file）添加到暂存区 stage 中进行追踪。

需求二，如何把 stage 中的修改还原到 work dir 中。

1

git checkout xxx

风险等级：中风险。

理由：在 work dir 做出的「修改」会被 stage 覆盖，无法恢复。所以使用该命令你应该确定 work dir 中的修改可以抛弃。

需求三，将 stage 区的文件添加到 history 区。

1

git commit -m '一些描述'

commit 完之后，突然发现一些错别字需要修改，又不想为改几个错别字而新开一个 commit 到 history 区，那么就可以使用下面这个命令：

1

git commit --amend

这样就是把错别字的修改和之前的那个 commit 中的修改合并，作为一个 commit 提交到 history 区。

风险等级：无风险。

理由：不会改变任或撤销任何已作出的修改，而且还会将 stage 区的修改加入 history 区并分配一个 Hash 值。只要不乱动本地的 .git 文件夹，进入 history 的修改就永远不会丢失。

需求四，将 history 区的文件还原到 stage 区。

1

git reset --mixed HEAD a.txt

其中，mixed 是一个模式（mode）参数，如果 reset 省略这个选项的话默认是 mixed 模式；HEAD 指定了一个历史提交的 hash 值；a.txt 指定了一个或者多个文件。

该命令的自然语言描述是：不改变 work dir 中的任何数据，将 stage 区域中的 a.txt 文件还原成 HEAD 指向的 commit history 中的样子。就相当于把对 a.txt 的修改从 stage 区撤销，但依然保存在 work dir 中，变为 unstage 的状态。

风险等级：低风险。

理由：不会改变 work dir 中的数据，会改变 stage 区的数据，所以应确保 stage 中被改动数据是可以抛弃的。

需求五，将 work dir 的修改提交到 history 区。

先 git add 然后 git commit 就行了，或者一个快捷方法是使用命令 git commit -a。

风险等级：无风险。

理由：显而易见。

需求六，将 history 区的历史提交还原到 work dir 中。

git checkout HEAD .

work dir 和 stage 中所有的「修改」都会被撤销，恢复成 HEAD 指向的那个 history commit。

类似之前通过 stage 恢复 work dir 的 checkout 命令，这里撤销的也只是修改，新增的文件不会被撤销。

只要找到任意一个 commit 的 HASH 值，checkout 命令可就以将文件恢复成任一个 history commit 中的样子：

git checkout 2bdf04a some_test.go

风险等级：高风险。

理由：这个操作会将指定文件在 work dir 的数据恢复成指定 commit 的样子，且会删除该文件在 stage 中的数据，都无法恢复，所以应该慎重使用。

其他技巧

需求一，合并多个 commit。

比如说我本地从 17bd20c 到 HEAD 有多个 commit，但我希望把他们合并成一个 commit 推到远程仓库，这时候就可以使用 reset 命令：

$ git reset 17bd20c
$ git add .
$ git commit -m 'balabala'

回顾一下刚才说的 reset 命令的作用，相当于把 HEAD 移到了 17bd20c 这个 commit，而且不会修改 work dir 中的数据，所以只要 add 再 commit，就相当于把中间的多个 commit 合并到一个了。

需求二，由于 HEAD 指针的回退，导致有的 commit 在 git log 命令中无法看到，怎么得到它们的 Hash 值呢？

再重复一遍，只要你不乱动本地的 .git 文件夹，任何修改只要提交到 commit history 中，都永远不会丢失，看不到某些 commit 只是因为它们不是我们当前 HEAD 位置的「历史」提交，我们可以使用如下命令查看操作记录：

git reflog

比如 reset，checkout 等等关键操作都会在这里留下记录，所有 commit 的 Hash 值都能在这里找到，所以如果你发现有哪个 commit 突然找不到了，一定都可以在这里找到。

需求三，怎么解决冲突？

记住，Git 虽然高大上，但也不要迷恋，一定要懂得借助先进的工具。

比较流行的代码编辑器或者 IDE 都会集成方便的可视化 Git 工具，至于解决冲突，可视化的表现方式不是比你在命令行里 git diff 看半天要清晰明了得多？只需要点点点就行了。

所以说，只要明白本文讲的这些基本操作，够你用的了，平时能用图形化工具就多用图形化工具，毕竟工具都是为人服务的。