likes
comments
collection
share

VSCode-通过GitLens插件完成git工作流

作者站长头像
站长
· 阅读数 1

前言

在真正项目中使用git之前，我看了很多文章，也在一些在线的git[练习网站](Learn Git Branching)上操作过。但始终不是真正的项目，并没有领悟到git其精髓所在，更不用说在工作中如何使用了。

后来工作中的项目中遇到之后，一开始也很懵逼，不知道怎么去使用。合并分支、解决冲突、跨分支开发、代码回滚等等。一路摸爬滚打，现在对正常的工作中会遇到的场景基本都能灵活运用了。

希望能帮到有需要的同学们。

GitLens

从VSCode拓展商店下载Gitlens

下载之后左侧的分支图标就是了 VSCode-通过GitLens插件完成git工作流

  • 源代码管理
  • COMMITS
  • FILE HISTORY
  • BRANCHERS
  • REMOTES
  • STASHES
  • TAGS
  • SEARCH & COMPARE

源代码管理

这部分是日常使用最频繁的模块。主要用于提交commit、合并后解决冲突、stash工作内容（用于跨分支开发）。

  • 修改过的文件会放在工作区
  • 工作区的文件可以添加到暂存区（git add）。
  • 每次提交（git commit）时，会将暂存区的内容形成一次完整的提交记录commit

VSCode-通过GitLens插件完成git工作流

提交commit流程

  1. 将工作区文件添加到暂存区。鼠标放到更改栏上方，点击+号图标，将全部工作区的文件添加到暂存区。如果不想全部提交的话可以对每个文件进行暂存处理，操作方式是单独点击单个文件右侧的+号图标。（PS:如果误添加了文件到暂存区也不要慌，在暂存区找到对应的文件，点击文件右侧的-号即可回退到工作区）。
  2. 执行提交操作。写完提交记录后，鼠标放到源代码管理栏，点击按钮√，完成本次提交。

跨分支工作流程

实际工作中可能遇到这样一种情况。你正在分支A进行功能开发，但是突然有个线上bug需要进行紧急修复，需要切换到对应的上线分支分支B进行bug修复。

那么正常来说我们需要先把分支A的修改提交。可是你在A分支的工作没有完全完成，追求完美的你又不想提交一次半吊子？的工作内容。此时git stash就可以完美地解决你的苦恼。

你只需要将鼠标放到更改栏上方，找到Stash All Changes按钮（就是那个重置按钮上带+号的），点击后git将会把你全部的工作区内容存储起来，然后你便会看到空空如也的工作区。此时你便可以切换到分支B进行刺激的线上bug修复啦[狗头]！

最后，当你拖着疲惫的身躯改完bug的后，回到分支A，重新取回之前存储的修改（见下图）：点击STASH栏，找到你存储的修改，点击Apply Stash按钮，在弹出的选框中选择Pop Stash便大功告成，回来了全都回来了！

（Apply和pop的区别在于：Apply不会删除掉stash中的存储记录，而pop会删除）

VSCode-通过GitLens插件完成git工作流

COMMITS

COMMITS栏会显示当前分支的所有提交，可以查看每个提交的更改明细。

这里主要讲一下如何进行版本回退git reset。

敲黑板，划重点

建议回退之前将工作区和暂存区的内容都提交上去，如果你不想要这些工作内容那么就当我没说。

在你想要回滚到的版本commit右键，选择Reset Current Branch to Commit，在弹出的选框中选择Hard Reset，回滚完成。

Soft Reset回滚的同时会将工作区的内容保留（leaves）

Hard Reset回滚的同时会将工作区的内容丢弃！丢弃！丢弃！（discards），所以一定慎重执行Hard Rest

git reflog

众所周知，git reset之后，git会维护一棵干净的提交记录树呈现给我们，带来的结果就是回滚到的版本就是当前分支的最新提交。那么问题来了，如何找到被git reset丢弃的那部分commit？

此时我们可以执行命令行git reflog，执行后你会发现，所有的提交记录甚至是操作记录全部都记录在此。一切又都回来了！实际上git不会删除任何一次的commit。

接下里你需要做的就是找到你想要去往版本的哈希值（复制前6位就好），执行git reset --hard commit对应的hash值，舒服~

总之，git中任何一次commit都是可以随意进行切换的。所以养成良好的commit习惯至关重要！

VSCode-通过GitLens插件完成git工作流

VSCode-通过GitLens插件完成git工作流

2022-09-28补充rebase部分内容

git-rebase 变基

切记：不要在共享分支上进行变基

切记：不要在共享分支上进行变基

切记：不要在共享分支上进行变基

作用

官方文档

顾名思义，变基就是改变基点。

将当前分支与目标分支先进行比较，找出当前分支领先于目标分支的commits，将这些commits按顺序放到目标分支。

命令

git rebase xxx

将当前分支变基到xxx分支（一般来说是主分支或者预发分支）

操作流程

变基的过程中，需要处理每一次冲突。

处理完单次冲突后，需要git add .添加到暂存区，然后git rebase --continue（类似变基过程中的git commit）提交本次合并，并进行下一次的冲突处理。

变基完成后再merge到主分支。

git checkout feat/branch
git rebase main
...处理冲突
git add.
git rebase --continue

# 变基完成后 合并到主分支
git checkout main
git merge feat/branch

git rebase -i xxx 交互模式

(题外话：并不清楚这个命令跟rebase有什么关系)

作用之一

合并提交

日常开发中，往往会将一些与功能本身没有太多关系的代码提交。

如果不进行提交合并的话，这些没有意义的提交上生产后会被带入主分支，不优雅[狗头]。

那么此时就可以合并提交操作，修改提交历史，展示一个清晰合理的提交历史。

命令

git rebase -i commit-hash

将commit-hash值（不包含该commit）之后的commit合并为同一个commit

git rebase -i HEAD~n

将前n个commit合并为同一个commit

操作流程

  1. git rebase -i commit-hash
  2. 按i键进入编辑模式
  3. 将最上面的一次提交设置为pick，其他的提交设置为squash。
  4. 按ESC键然后输出:wq，保存并退出
  5. 在之后出现的编辑页面继续按i键进入编辑模式，整理commit信息（不需要的直接删除就行dd快速删除行）

例1

pick hash1 update readme
pick hash2 commit1
pick hash3 commit2
pick hash4 commit3
# 修改为->
pick hash1 update readme
pick hash2 commit1
s hash3 commit2
s hash4 commit3

hash1会被保留

hash2、hash3、hash4合并为1个commit，并且整合commit message

相当于原本的4次commit变成了2次commit

例2

pick hash1 update readme
pick hash2 commit1
pick hash3 commit2
pick hash4 commit3
# 修改为->
pick hash1 update readme
pick hash2 commit1
s hash3 commit2
r hash4 commit3

hash1会被保留

hash2和hash3合并为1个commit，并且整合commit message

hash4会被保留，但可以修改commit的message

相当于原来的4次commit变成了3次commit

总结

以上就是我在VSCode中通过GitLens插件的一些工作流程。

其实不用纠结使用什么工具，只要熟悉了git的工作模式，多实操几次。其他的工具都是融会贯通的，命令行或者SourceTree也都能很快上手的~