git相关的小技能(常用的git操作有哪些)
你所不知道的一些git相关的小技能
前言
为什么要写这个文章呢？其实发现很多同学对一些很简单又有效的 git 手段都不太了解，下面结合使用场景介绍几个性价比极高的git指令。
贴出官方文档以便大家进一步学习 Git
后悔药
我们在日常开发时,偶尔会不小心提交错代码，分别在工作区,暂存区,版本库等以上场景. 来让我们看看,有什么好的解决方案
应用背景
1.想象一下这个场景,我们刚拉下代码进行调试,针对产品,想出了有两个组件可能符合此次功能方案。我们首先尝试一下方案a。此时方案a不可行，我们使用方案b，可这时候方案a已在工作区中存有了一些代码,我们要如何处理呢。
$ git checkout filePath // 指令可清空工作区.可完美实现该场景需求。复制代码
2.同上场景,如果此时代码由工作区跑到了暂存区,我们又该如何处理呢
$ git restore --staged filePath // 指令可撤回暂存区的代码回到工作区。 $ git restore filePath // 指令可撤回暂存区的代码取消跟踪状态。复制代码
3.如我们已经完成以上场景,并且最后进行了代码提交,由于我们代码commit管理比较严谨，此时你的提交代码注释中,不小心多打了几个怪怪的符号,这在不影响提交记录的情况下,我们该如何处理呢
$ git commit --amend // 可直接打开.git文件夹下的存储注释的相关文件夹,直接快捷修改上一次提交文件. 在几个增删改linux操作后.退出文件夹即可完成二次提交，此时的git log 仍是上一次的HASH值.不会创建新的提交记录.复制代码
4.以上分别在工作区,暂存区,commit对象相关进行了撤销.那么如果我们在本地/远程版本库中操作有误又该怎样弥补呢
这是我专门写的介绍这种回滚方式,有兴趣的同学可以看看
url: # git - 简述三种'代码回滚'方式
git cherry-pick
择优挑选commit记录进行合并.
应用背景
想象一下这个场景,想在某个稳定版本上，添加一个刚开发完成的版本中的功能。就可以使用 Cherry-pick 命令，将这个功能相关的 commit 提取出来，合入稳定版本的分支上。
$ git reflog // 查看本地所有分支提交记录,拿到相关commitHASH(提交索引) $ git cherry-pick commitHASH filePath // a分支从b分支中拿到稳定功能提交记录,进行合并。复制代码
文件版本差异比较
在日常工作中我们有时候会不小心在某个函数代码块放置错了代码,发现项目运行跑不起来,又不知晓我们改动了哪里这时候,想先看下当前文件代码与历史记录,在不借助插件的情况下我们该如何操作呢？
应用背景
当前文件
工作区代码与当前文件历史提交记录做比较$ git log --oneline // 查看分支未删减的提交记录简易版,拿到相关commitHASH(提交索引) $ git diff commitHASH filePath // 拿当前工作区代码与拿到的历史提交记录的当前文件做比较。复制代码
当前文件
暂存区代码与当前文件历史提交记录做比较$ git log --oneline // 查看分支未删减的提交记录简易版,拿到相关commitHASH(提交索引) $ git diff --cached commitHASH filePath // 拿当前工作区代码与拿到的历史提交记录的当前文件做比较。复制代码
当前文件
版本库代码不同历史提交记录做比较$ git log --oneline // 查看分支未删减的提交记录简易版,拿到相关commitHASH(提交索引) $ git diff commitHASH commitHASH2 filePath // 当前文件下历史记录做比较复制代码
注:以上比较去掉
filePath可做比较当前项目下全文件差异
代码暂存
在日常工作中我们有时候开发a功能的时候,产品这时候告诉你b功能比较紧急,但是此时的代码又不构成一次提交,这时我们该怎么做呢
使用 git stash 将更改的文件存储在工作目录中-
.git/refs/stash
应用
增:存储当前已跟踪的文件在暂存区中但又不构成一次提交的文件
$ git stash // 将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动复制代码
查:查看当前已经存储的暂存索引
$ git stash list // 查看存储复制代码
用:根据stash索引拿到存储的内容
$ git stash apply stash@{index} // 查看存储的哪些内容,根据stash索引拿到存储的内容复制代码删:移除存储的内容
$ git stash drop stash@{index} ：// 丢弃stash@{index}存储，从列表中删除这个存储 $ git stash clear ：// 删除所有缓存的stash复制代码
配别名(巨实用
在日常工作中
git并不会在你输入部分命令时自动推断出你想要的命令。 如果不想每次都输入
完整的 git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。
应用
在查询当前log信息时，要敲 git status 等单词会敲错
$ git config --global alias.st status // 配置全局git status命令别名 $ git st //即可 $ git config --global alias.ci commit // 配置全局git commit 命令别名 $ git ci -m "xxx xxx xxx..." //即可 复制代码
一次性配置多个别名，直接修改配置文件
win下面的可以用 everything工具直接搜全局 .gitconfig 文件位置,在其中修改即可.复制代码
git工作流程
在日常工作中难免设计到团队多人协作开发,协作必须有一个规范的工作流程,让大家高效的合作,使得项目井井有条地发展下去。下面我们了解一下比较常见的三种规范
Git flowGithub flowGitlab flow
git flow
项目存在两个长期分支前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
- 主分支`master` - 开发分支`develop`复制代码
项目存在三种短期分支，一旦完成开发，它们就会被合并进
develop或master，然后被删除。- 功能分支（feature branch） - 补丁分支（hotfix branch） - 预发分支（release branch）复制代码
github flow
它只有一个长期分支，就是
master，因此用起来非常简单.一般用于开源项目- 主分支`master`复制代码
工作流程
- 先 fork 别人的仓库. - clone 到本地分支，做一些功能开发, bug fix(修复 - 发起 pull request 操作给原仓库，让他看到你修改的 bug - 原仓库 review 这个 bug，如果是正确的话，就会 merge 到他自己的项目中合并进`master`复制代码
gitlab flow
Gitlab flow 是 git flow 与 github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 gitlab.com 推荐的做法。
重点
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master， 它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。复制代码
持续发布的项目
对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。 比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是 开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。 比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题， 再cherry-pick到pre-production，这一步也没有问题，才进入production。 只有紧急情况，才允许跳过上游，直接合并到下游分支。production。复制代码
版本发布的项目
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支， 比如2-3-stable、2-4-stable等等 以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号
伪原创工具 SEO网站优化 https://www.237it.com/
作者：李白爱喝水
链接：https://juejin.cn/post/7036133311730679844