Git常用功能总结
发表开发周边 / Git11 分钟读完 (大约1626个字)0次访问

Git常用功能总结

1 基础概念

1.1 工作区 / 暂存区 / 本地仓库 / 远程仓库

首先，先了解一下 Git 的构成部分可以帮助我们在后面使用 Git 指令时容易理解其实现原理。


  • Workspace：工作区：项目文件所在目录，可能包含一个 .git(本地仓库) 子目录
  • Staging Area：暂存区：也称为索引，其中所存储的是我们为下一次提交准备的内容，它以快照的形式保存了相关的文件内容
  • Local Repository：本地仓库：本机，通常驻留在项目的 .git 目录中
  • Remote Repository：远程仓库，非本机上的 Git 仓库，一般会是 GitHub

1.2 相关的 Git 命令

clone 远程仓库的代码到本地：

1
git clone <远程仓库地址>

把工作区修改的代码提交到暂存区：

1
git add .

把暂存区内容提交到本地仓库：

1
git commit -m "feat: 提交说明"

把本机仓库内容 push 到远程仓库上：

1
git push origin <分支名>

fetch 相关指令：
将某个远程主机的更新，全部取回本地：

1
git fetch <远程主机名>

取回特定分支的更新，可以指定分支名：

1
git fetch <远程主机名> <分支名>


pull 和 fetch 的区别：
pull 相当于 fetch 和 merge 的这两步操作：

1
2
git fetch origin master // 从远程主机的 master 分支拉取最新内容
git merge FETCH_HEAD // 将拉取下来的最新内容合并到当前所在的分支中

2 基础配置

Git 安装成功后做以下配置：

2.1 设置提交用户

每个机器都必须自报家门：你的名字和 Email 地址。

1
2
git config --global user.name "杨静"
git config --global user.email "[email protected]"

2.2 设置合并方式

为了能够让每一次提交都有明确的记录，统一使用 rebase 方式提交代码。在 Git Bash 中执行：

1
git config --global pull.rebase true

2.3 设置换行符

Windows 使用回车和换行两个字符来结束一行，而 Mac 和 Linux 只使用换行一个字符。Windows 系统可以在提交代码前输入命令：

1
git config --global core.autocrlf false

Windows 系统如果不设置换行符的话，项目代码拉取运行后可能会报下面的错误：

2.4 查看 Git 配置信息

用户名和账号配置好后查看下最终配置信息：

1
git config --list

3 撤销修改

3.1 撤销工作区内容

场景： 自从上次代码提交后，我们写了一些测试时用的代码例如 debugger、console.log() 等等。等我们测试完后我们并不想保存这些代码，想把他们从工作区删除掉，这个时候我们就可以使用 Git 的撤销功能。

3.1.1 使用 git checkout 撤销工作区修改

​

撤销指定文件在工作区的修改：

1
git checkout -- <file>

撤销所有文件在工作区的修改：

1
git checkout -- .


注意：git checkout -- file 命令中的 – 很重要，没有 -- 就变成了 切换到另一个分支 的命令，我们在后面的分支管理中会再次遇到 git checkout 命令。

3.1.2 使用 git restore 撤销工作区修改

可能是因为 Git 版本不一样，我的电脑执行 git status 后是提示我使用 git restore 命令进行撤销的。

1
git restore <file>...


所以也就是说你在执行 git status 命令后，你可以使用 Git 提示的那个命令进行撤销操作。

3.1.3 使用小乌龟撤销工作区修改

使用小乌龟撤销工作区修改内容：
第一步： 选择 Revert 功能


第二步：选中你要撤销修改的文件点确定。

3.2 撤销暂存区内容

场景：假使自从上次提交代码后你写了一些测试代码，由于加班到凌晨三点脑子已经不好使了，习惯之下进行了 git add . 操作，庆幸的是在 commit 之前发现了这个问题，执行 git status 看一下，修改只是存到了暂存区，并没有提交。

3.2.1 使用 git reset 撤销暂存区内容

撤销指定文件暂存区的修改，重新放回工作区：

1
git reset HEAD <file> // HEAD 也可以用 commitid 代替

撤销所有文件暂存区的修改，重新放回工作区：

1
git reset HEAD .

撤销所有文件暂存区的修改，直接撤销掉，不会重新放回工作区：

1
git reset --hard HEAD // --hard 在这有一步到位的意思

已经执行 git add . 提交了暂存区，但是没有 commit：
可以使用 git reset HEAD 把暂存区的修改撤销掉（unstage），重新放回工作区。如果工作区也想清掉的话再执行一下刚才的 git checkout – 指令。git reset 命令既可以进行版本回退，也可以把暂存区的修改回退到工作区。当我们用 HEAD 时，表示最新的版本。

3.2.2 使用 git restore 撤销暂存区内容

可能是因为 Git 版本的问题，同样，我的电脑执行 git status 命令后，Git 提示我使用 git restore 进行回退。

3.3 撤销本地仓库内容（版本回退）

场景：git reset –hard 适合我们提交了错误的内容后进行回退的命令，因为执行这个命令后 Git 并不会将代码重新放回工作区。
Git 实现版本回退的原理是通过让 HEAD 这个指针指向其它版本来完成版本回退。

3.3.1 使用 git reset 实现版本回退

如果我们已经把内容 commit 到了本地仓库里，那么如果想撤销的话可以按照以下步骤：
第一步：查看历史提交记录，找到你想回退到那个版本的 commitid，copy 下来备用。

1
git log

第二步：执行 git reset 实现版本回退

1
git reset --hard commitid

注意：执行 git reset –hard 进行版本回退后，并不会重新把你提交为 commitid 的内容重新放回工作区。


拓展 1：在第二个步骤中如果你想回退至上一个版本，也可以用命令 git reset --hard HEAD^ 来实现，因为在 Git 中，使用 HEAD 表示当前版本，那上一个版本就是 HEAD^，上上个版本就是 HEAD^^，当然往上 100 个版本写 100个 ^ 比较容易数不过来，所以写成 HEAD~100。
​

拓展 2：现在，你已经成功回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commitid怎么办？
在 Git 中，总是有后悔药可以吃的：

  1. 使用 git reflog 查看每次的提交命令。
  2. 执行 git reset –hard commitid

好了，就这样我们又乘坐时光机回到了未来。

4 分支管理

下图中的 HEAD 可以理解为指向 commit 对象的可变指针。

4.1 分支说明

为了避免代码合并经常会出现的冲突，保证随时拥有可发布的版本，使得持续集成和持续部署成为可能，我们采用基于主干的开发方式。分支可包含以下类型：

  • master：主干分支，唯一一个长期存在的分支。所有的开发人员基于此分支进行开发，无特殊情况，提交直接 push 到这个分支上。
  • release：发布分支，紧急情况下需要进行版本发布的时候，从 master 创建发布分支，进行测试完善，最终修改代码要合并回 master 分支。非特殊情况均通过 master 分支进行发布。

如无特殊情况，原则上禁止以下分支的创建。如想使用可以在本地按如下规范创建：

  • feature/*：特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支。
  • bugfix/*：bug 修复分支，用于修复不紧急的 bug，开发完成自测没问题合并进 master 分支后，删除该分支。
  • hotfix/*：紧急 bug 修复分支，该分支只有在紧急情况下使用，从 release 分支创建，修复完成后，需要合并该分支到 release 分支，同时需要再合并回 master 分支。

4.2 创建与合并分支

说明：使用 Git 命令在本地新建的分支都属于本地分支，push 到远程之后远程仓库上才有此分支。

4.2.1 原理

我们在切换分支，和新建分支的时候，有没有想过，这些操作背后的工作原理是怎样的呢？最大的功臣就是 .git 目录下的 HEAD 引用，它从一个分支跳到另一个分支，虽无声无息，却精准无比。
​

下面一块来看一下 Git 是如何通过改变 HEAD 指向来实现创建、合并分支的。
​

一开始的时候，master 分支是一条线，Git 用 master 指向最新的提交，再用 HEAD 指向 master，就能确定当前分支，以及当前分支的提交点：


当我们创建新的分支，例如 dev 时，Git 新建了一个指针叫 dev，指向 master 相同的提交，再把 HEAD 指向 dev，就表示当前分支在 dev 上：


你看，Git创建一个分支很快，因为除了增加一个 dev 指针，改改 HEAD 的指向，工作区的文件都没有任何变化！
​

从现在开始，对工作区的修改和提交就是针对 dev 分支了，比如新提交一次后，dev 指针往前移动一步，而 master 指针不变：


当我们在 dev 上的工作完成了之后，就可以进行分支合并了，把 dev 分支合并到 master 分支上，其实 Git 的做法就是改变一下指针指向，把 master 分支指向 dev 的当前提交，就完成了合并。


完成了分支合并后，就可以把本地的 dev 分支给删除掉了，删除后就又剩下一个 master 分支。



**总结**：
  1. 一条时间线就是一个分支，HEAD 指向的那个分支也就是当前分支。
  2. Git 合并分支（Fast-forward 模式）其实很快！就改改指针，工作区内容也不变。

4.2.2 实战

​

首先，我们创建 dev 分支，然后切换到 dev 分支：

1
2
$ git checkout -b dev
Switched to a new branch 'dev'

git checkout 命令加上 -b 参数表示创建并切换，相当于以下两条命令：

1
2
3
$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用 git branch 命令查看当前分支：

1
2
3
$ git branch
* dev
  master

git branch 命令会列出所有分支，当前分支前面会标一个 * 号。
然后，我们就可以在 dev 分支上正常提交，比如对 readme.txt 做个修改，加上一行：

1
## 这是 dev 分支的内容

把上方内容提交之后，执行 git checkout master 切换回 master 分支，这时候发现刚才提交的内容不见了，这是因为 master 分支此刻的提交点并没有改变：


现在，我们把 dev 分支的工作成果合并到 master 分支上：

1
2
3
4
5
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

git merge 命令用于合并指定分支到当前分支。合并后，再查看 readme.txt 的内容，就可以看到，和 dev 分支的最新提交是完全一样的。
​

拓展：注意到上面的 Fast-forward 信息，Git 告诉我们，这次合并是“快进模式”，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward，我们后面会讲其他方式的合并。


合并完成后，就可以放心地删除 dev 分支了：

1
2
$ git branch -d dev
Deleted branch dev (was b17d20e).

删除后，查看 branch，就只剩下 master 分支了：

1
2
$ git branch
* master

因为创建、合并和删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在 master 分支上工作效果是一样的，但过程更安全。但是分支合并时很可能要解决冲突，很可能要花时间解决冲突，所以虽然 Git 鼓励你使用分支来完成某个任务，但是要不要新建分支还是需要你视情况而定。
​

4.2.3 拓展内容

4.2.3.1 使用 switch 命令切换分支

刚才我们知道使用 git checkout <branch> 命令可以切换分支，前面讲撤销工作区内容的时候是使用 git checkout -- <file> 。这两种方式很容易让人弄混 git checkout 的用法。所以 Git 新版本就使用 git switch 分支来切换分支，更语义化。
​

创建并切换到新的 dev 分支：

1
git switch -c 分支名

直接切换到已有分支：

1
git switch 分支名

4.2.3.2 git merge 和 git merge –no-ff 的区别

Fast-forward 方式就是当条件允许的时候，Git 直接把 HEAD 指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建 commit。如果要强制禁用 Fast forward模式，Git 就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。
​

下面我们一起看一下使用–no-ff 禁用掉 Fast-forward 模式的 git merge 合并方式：
​

首先，仍然创建并切换 dev 分支：

1
2
$ git switch -c dev
Switched to a new branch 'dev'

修改 readme.txt 文件，并提交一个新的 commit：

1
2
3
4
$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)

现在，我们切换回 master：

1
2
$ git switch master
Switched to branch 'master'

准备合并 dev 分支，请注意 –no-ff 参数，表示禁用 Fast forward：

1
2
3
4
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的 commit，所以加上 -m 参数，把 commit 描述写进去。
合并后，我们用 git log 看看分支历史：

1
2
3
4
5
6
7
$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

可以看到，不使用 Fast forward 模式，merge 后就像这样：


之前使用 Fast forward 模式合并， merge 后是这样子的：


4.2.4 总结

  1. 查看分支：git branch
  2. 创建分支：git branch
  3. 切换分支：git checkout 或者 git switch
  4. 创建+切换分支：git checkout -b 或者 git switch -c
  5. 合并某分支到当前分支：git merge 或者 git merge –no-ff -m “提交说明” <分支名>
  6. 删除已被合并过的分支：git branch -d
  7. 删除还未被合并的分支：git branch -D
  8. 分支合并时 –no-ff 的作用: 合并分支时，加上–no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 Fast forward 合并就看不出来曾经做过合并。

4.3 解决冲突

前面我们合并分支时 Git 输出的信息有一个 Fast-forward Git 告诉我们，这次合并是“快进模式”，也就是直接把 master 指向 dev 的当前提交。但是合并操作并不总是简单的改变指针指向的这种 “快进模式”的。当 Git 无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
​

先来制造一个冲突的场景
新建 feature1 本地分支：

1
2
$ git switch -c feature1
Switched to a new branch 'feature1'

修改 readme.txt 最后一行，改为下方文字后执行 git add . 和 git commit 提交。

1
Creating a new branch is quick AND simple.

切换到 master 分支并修改 readme.txt 文件最后一样为下方文字并进行提交：

1
Creating a new branch is quick & simple.

现在，master 分支和 feature1 分支各自都分别有新的提交，变成了这样：


这种情况下，Git 无法执行“快速合并”，因为 HEAD 指针简单的指向谁都不能完成最终的合并，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。
我们切换到 master 分支后把 feature1 分支合并到 master 分支：

1
2
3
4
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

这个时候我们就需要手动解决冲突，冲突解决后再进行提交。
​

解决冲突时你要清楚的知道 Current Change 和 Incoming Change 的代码都来自哪里。



最后就是删除掉 feature1 本地临时分支： 
1
2
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

拓展：使用 git log --graph --pretty=oneline --abbrev-commit 指令也可以看到分支的合并情况：
​

总结：

  1. 当 Git 无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
  2. 解决冲突就是把 Git 合并失败的文件手动编辑为我们希望的内容，再提交。
  3. 用 git log –graph 命令可以看到分支合并图。

4.4 分支使用时常遇问题

4.4.1 使用 git stash 解决问题

场景1：当你正在开发一个功能 A 时，刚开发到一半突然接到需要在一小时内修复一个 bug，但是功能 A 的工作预计还要一天才能开发完，当时在 dev 分支开发的一一部分功能 A 功能也还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，但是又必须在 1 小时内修复 bug 该怎么办？

这个时候就可以用到 Git 提供的 stash 功能了：
​

先把当前工作现场“储藏”起来（相当于还原到和服务器上一样的代码，当前工作区是干净状态）。

1
2
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

现在，用 git status 查看工作区，git 显示工作区是干净的，现在可以放心的修改 bug 了。
​

现在修复 bug，需要把“现在存在一个 bug”改为“bug 修复完成”，然后提交。

1
2
3
4
$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

bug 修复后，提交代码后使用 git status 发现当前工作区是干净的，刚才的工作现场存到哪去了？用 git stash list命令看看

1
git stash list

是时候把存储起来的功能 A 代码恢复回来继续工作了，有两种恢复方式。

  1. 一是用 git stash apply 恢复，但是恢复后，stash 内容并不删除，你需要用 git stash drop 来删除。
  2. 用 git stash pop，恢复的同时把 stash 内容也删了
1
2
git stash pop
git stash apply

再用 git stash list 查看，就看不到任何 stash 内容了：
​

你可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令：

1
git stash apply <stash的索引值>

删除保存的 stash：

1
git stash drop

场景 2：当你往远程仓库 push 代码时，本地版本 < 远程版本时，并且你本地还有未 add 的代码时，Git 就会提示你 The current working tree is not clean。
如果使用的是小乌龟的话它会这样提示：


​

这个时候你也可以先把本地为提交的代码使用 stash 功能给存储起来，把代码 push 到远程后再使用 git stash pop 或 git stash apply 把存储的代码给恢复。
​

场景 3：平常我们新开发一个功能要建个分支，修改个 bug 也要建个分支，我们经常要对不同分支进行操作，然而原本我是想在 feature 分支开发一个新功能，但是代码却写在了 test 分支上了。
​

  1. 在 test 分支上执行 git stash，先把代码存储起来。
1
git stash
  1. 执行 git switch feature 切换到 feature 分支。
1
git switch feature
  1. 执行 git stash pop 把存储的代码释放出来，并清空 stash 存储的代码。
1
git stash pop

4.4.2 使用 cherry-pick 解决问题

场景1：假如我们要在 master 分支上修复 bug，bug 修复好后，我们一想 dev 是开发分支，如果 master 分支上存在 bug，那 dev 分支上肯定也有这样的一个 bug，那么我们要怎么做呢，难道要把修复 bug 的代码一行一行复制过去吗？
​

我们有更简单的方法：

  1. 我们找到并修复 bug A 提交的 commitid
  2. 然后切换到 dev 分支
  3. 使用 git cherry-pick commitid 命令去复制提交为 commitid 的那次代码到 dev 分支

​

用 git cherry-pick，我们就不需要在 dev 分支上手动再把修改 bug 的过程重复一遍。
​

场景 2：release 分支是项目的预发布环境，平时我们只能把 main 分支上的代码整个全部给合并到 release 分支上，这时候需求问现在需要给客户演示刚才小明同事新增的地图功能，但是现在 main 分支上的代码还没经过测试，不能完全合并过去，呃……
​

这个时候也可以使用 git cherry-pick 来实现上诉需求。具体做法可以参考下面步骤：
​

  1. 在 main 分支上通过 git log 查看日志，将自己提交的该功能对应的 commitid 值整理出来。
  1. 如果本地没有 release 分支，需要先将 release 分支从远程仓库拉到本地仓库(如果本地有 release 分支，并且已与远程对应的 release 分支已关联，无需这一步，直接到下一步)
1
git checkout --track origin/release
  1. 切换到 release 分支
1
git checkout release
  1. 在 release 分支上操作：通过 git cherry-pick <commit 对应的 hash 值>将当前 hash 对应提交的代码合并到 release 分支上去。
1
git cherry-pick <commitid>
  1. 最后将本地合并好的 release 分支 push 到远程的 release 分支上去。
1
git push origin release

​

场景 3：在 main 分支上开发了 A、B、C、D 等功能，现在只需把 main 分支上的 A 功能合并到 release 分支，B、C、D 功能不做合并。
​

比如说我这个时候功能 A 的代码提交次数有多次 commitid3~commitid10 都是功能 A 的开发提交，或则是提交次数有多次但是 commitid 不是连续的，中间也有其它人提交。那么这两种情况下如果和功能 A 相关的开发有 10 次提交，那么我们需要执行 10 次 git cherry-pick commitid 吗？
​

答案肯定是没有必要的，下面再来介绍一下有关 git cherry-pick 的拓展知识：
拓展：​

  1. 单个 commit 合并
1
git cherry-pick commitid
  1. 多个分开的 commit 一起合并
1
git cherry-pick commit-id1 commit-id3 commit-id6
  1. 多个连续的 commit 合并， 将 commitid1到 commitid8 之间的所有提交合并到 release 分支上（不包含第一个 commitid）
1
git cherry-pick commitid1..commitid8

每一次合并都可能会产生冲突，如果产生冲突，先解决冲突，然后将代码 commit 到本地仓库即可。
​

注意：测试无误之后，再将合并后的代码push到远程仓库。切记！

4.4.3 如何丢弃没有被合并过的分支

场景：我们正在开发一个庞大的功能 B，为了不影响主分支上的功能，就新建了一个 feature-vulcan 分支来开发功能 B，功能开发完了，准备合并，接到领导通知说客户改变想法了，不想要此功能了，此功能又涉及到保密工作，所以客户要求要立即销毁。
​

所以我们执行 git branch -d feature-vulcan，

1
2
3
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

销毁失败。Git友情提醒，feature-vulcan 分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的 -D 参数。。
现在我们强行删除：

1
2
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).

终于删除成功！

4.4.4 本地分支是否到 push 到远程仓库

本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

  • master 分支是主分支，因此要时刻与远程同步
  • dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步
  • bug 分支只用于在本地修复 bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个 bug
  • feature 分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发

总之，就是在 Git 中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定。

4.4.5 总结

  1. 修复 bug 时，我们会通过创建新的 bug 分支进行修复，然后合并，最后删除
  2. 当手头工作没有完成时，先把工作现场 git stash 一下，然后去修复 bug，修复后，再 git stash pop，回到工作现场
  3. 在 master 分支上修复的 bug，想要合并到当前 dev 分支，可以用 git cherry-pick 命令，把 bug提交的修改“复制”到当前分支，避免重复劳动
  4. 如果要丢弃一个没有被合并过的分支，可以通过 git branch -D 强行删除

5 git 常用操作

5.1 如何把本地项目推送到远程仓库

场景：想把本地的一个项目文件存到 github 远程仓库。
操作步骤：

1
2
3
4
5
6
7
8
1. 在本地建一个文件夹，例如 git-study-demo 作为本机工作区。
2. 使用 git init 命令来初始化一个 Git 仓库。
3. 把项目文件复制到 git-study-demo 目录下。
4. 执行 git add . 把所有文件存到暂存区。
5. 执行 git status 查看文件状态。
6. 执行 git commit -m "初始化项目模板"。把暂存区文件提交到本地库。
7. git remote add origin https://github.com/beyond-yang/study-git-demo.git 添加远程版本库
8. git push -u origin main 提交到远程仓库

说明：​
git push -u origin main 命令中的 -u 参数其实就相当于记录了 push 到远端分支的默认值，这样当下次我们还想要继续 push 的这个远端分支的时候推送命令就可以简写成 git push 即可。

5.2 git log 退出方法

使用 git log 命令之后，无法回到主页面，然后只能用暴力的方法解决，直接关闭命令窗口。


其实很简单，输入字母 Q 即可退出。

5.3 删除分支

删除已经合并过的分支：

1
git branch -b feature-1

强行删除没有合并过的分支：

1
git branch -D feature-1

5.4 在本地创建和远程分支对应的分支

1
git checkout -b branch-name origin/branch-name

5.5 建立本地分支和远程分支的关联

1
git branch --set-upstream-to=origin/<branch> dev

5.6 撤销合并操作

场景1：需求说要把综合查询合并到 release 分支，目的是发布到预发布环境，代码合并后发现有 bug，说是要撤销这次的代码合并。
release 分支是远程分支，肯定不能直接对远程分支进行撤销操作，可以在本地进行撤销后再 push 到远程上去：

1
git reset HEAD^

6 个人使用习惯

6.1 查看提交日志

查看提交日志喜欢使用界面化工具——例如小乌龟




因为界面化工具不仅可以很方便的看出提交记录，还可以看出每次提交记录都修改了哪些文件，以及文件的修改内容。

6.2 撤销工作区的修改

撤销工作区修改喜欢用界面化工具——例如小乌龟

6.3 提交代码

提交代码喜欢用界面化工具——例如小乌龟
为了防止提交错误的代码或无用的代码，所以每次提交代码时都习惯看一下修改的内容都有哪些，如果发现有一些测试代码如 console.log 或 debugger 之类的。就删除掉后再提交。


7 记录工作中遇到的问题

7.1 git 源换了之后应该怎么处理

场景说明：​
公司代码库迁移到另外的服务器，个人需要重新更新本地代码库，重新拉代码显然效率低，这时候只需要更换git源就可以轻松搞定
前提：本地代码已经更新到最新的 commit，更换源之后拉代码才不会出现冲突。
方法一：​

  1. 进入本地仓库路径，进入 .git 目录
  2. 修改 config 文件，将 url 换成现在的 git 仓库地址


方法二：
第一步查看源地址：

1
git remote -v

第二步删除源地址：

1
git remote rm origin

第三步添加源地址：

1
git remote add origin [email protected]:fei/stic.git

这就行了,然后git pull 拉取代码看有没有问题。
最后可以关联起来本地的分支(可忽略)：

1
git branch --set-upstream master origin/master

7.2 git 绿色、红色图标不显示问题的解决方案

问题：在使用git的过程当中发现，项目文件上没有绿色图标，即便修改文件也没有红色图标显示git
绿色图标是指提交成功的，红色图标是指修改后还未提交的。没有图标显示，可是能够正常上传下载，在文件比较多的时候，不知道本身修改了哪些，容易出现错误。
解决步骤：

  1. win+r,regedit.exe，打开注册表 按照文件的层次关系依次找到blog

HKEY_LOCAL_MACHINE\Software\Microsoft\windows\CurrentVersion\Explorer;排序
修改键名 Max Cached Icons (最大缓存图标) 的值为 2000 （没有这个键，能够新建）资源
重启电脑

  1. 打开后找到“HKEY_LOCAL_MACHINE–>SOFTWARE–>Microsoft–>Windows–>CurrentVersion–>Explorer–>ShellIconOverlayIdentifiers”这一项。将 Tortoise 相关的项都提到靠前的位置（重命名，在名称以前加几个空格）
  1. 重启电脑或重启资源管理器后，绿色和红色图标就显示出来了。

7.3 gitlab 页面添加 sshkey后，git pull 提示需要输入密码的问题解决

问题：本人电脑配置了sshkey 并且也clone 项目一段时间了，一天发现git pull 需要输入密码。很疑惑，检查了id_rsa配置都没有问题，一下是我的解决步骤：

  1. 执行 ssh -Tv 

    1
    ssh -Tv @git/xxx(your git repository)

    git_info

  2. 修改或新建”~/.ssh/config”文件，添加如下配置，gitlab.com 仅仅是实例，根据你的实际情况更换。

    1
    2
    Host gitlab.com 
    PubkeyAcceptedKeyTypes=+ssh-rsa

    最后，执行git 操作没问题了。

Git常用功能总结

https://first-jim.github.io/2022/09/05/Git常用功能总结/

作者

Jiaming

发布于

2022-09-05

更新于

2024-03-05

许可协议

#

喜欢这篇文章？打赏一下作者吧

评论

关注我

目录

链接

最新文章

归档

标签

Babel1
Blog1
Browserslist1
CORS1
CSS2
ES61
ESLint1
Git2
Gitlab CI2
HTML1
HTTP1
HTTP/HTTPS1
HTTPS1
JavaScript4
Mobx1
Mobx 状态机1
Mock1
Module2
Nest.js1
OpenSSH1
PWA1
Promise, async/await, event-loop1
Rap21
React1
SonarQube1
Storybook1
TypeScript1
Vue.js22
Vue.js31
Vue32
WebRTC1
cordova2
if-else1
pinia1
webpack1
七牛云oss1
中间件1
云原生1
优化1
元宇宙1
其他2
单元测试2
原型链1
常用功能1
开发周边1
微前端2
性能优化1
打包工具1
概念1
正则表达式1
算法题1
质量控制1
进程管理工具1

订阅更新

分类

×