匹配仓库标题、描述、README文件中的关键词
- shop
指定关键词所在位置
- shop in:name
- shop in:description
- shop in:readme
指定stars数量范围
- shop stars:>2000
- shop stars:<3000
指定forks数量
- shop forks:>3000
- shop forks:<5000
指定仓库主要语言
- shop stars:>3000 language:java
- shop stars:>3000 language:python
高亮代码块搜索
- 高亮第15行
- https://github.com/shopizer-ecommerce/shopizer/blob/master/pom.xml
#L15
- 高亮第15行到20行
- https://github.com/shopizer-ecommerce/shopizer/blob/master/pom.xml
#L15-L20
仓库中按照文件名搜索
git reset --soft 版本号 (撤销commit)
git reset --mixed 版本号 (撤销commit和add两个动作)
git reset --hard 版本号 (撤销并舍弃指定版本号之后的提交记录)(慎用)
本地使用后需要强制推送到远程同步下,因为本地分支没有远程新了
git push origin master -f
git pull 远程主机(config文件中查看) (远程分支) -f
git revert 版本号 (撤销,但是保留了提交记录)(推荐使用)
可能会提示冲突
git revert --abort (取消恢复再次执行试试)
一个远程代码库的一个分支由多人协作时的场景
用户A推送了代码,用户B再推送代码时会报错,提示远程代码库已被修改,这时需要拉取远程代码到本地后再次推送
前提是本地代码已commit
git pull origin master
git pull 远程主机(config文件中查看) (远程分支)
git push origin master
git pull 远程主机(config文件中查看) (远程分支)
拉取不相关代码时报错:
git pull origin master
git pull 失败 ,提示:
fatal: refusing to merge unrelated histories
其实这个问题是因为 两个 根本不相干的 git 库, 一个是本地库, 一个是远端库, 然后本地要去推送到远端, 远端觉得这个本地库跟自己不相干, 所以告知无法合并
具体的方法, 一个种方法: 从远端库拉下来代码 , 本地要加入的代码放到远端库下载到本地的库, 然后提交上去 , 因为这样的话, 你基于的库就是远端的库, 这是一次update了
第二种方法:使用这个强制的方法
git pull origin master --allow-unrelated-histories
后面加上
--allow-unrelated-histories
, 把两段不相干的 分支进行强行合并,之后推送到远程的master分支:git push origin master
git branch 列出所有本地分支
git branch -r 列出所有远程分支
git branch -a 列出所有分支
git branch name 新建一个分支,但仍停留在当前分支
git checkout -b [branch] 新建一个分支并切换到该分支
git checkout name 切换到指定分支
git checkout - 切换到上一个分支
git merge [branch] 合并指定分支到当前分支
git branch -d [name] 删除指定的本地分支
git push origin --delete name 删除指定远程分支
git push origin name 把本地分支上传到远程
git checkout -b 本地分支名x origin/远程分支名x
每个分支拥有独立的代码空间
切换分支其他命令
git switch [分支名]
当想从子分支切换到dev分支时git checkout dev
报错:
error: you need to resolve your current index first
xxx.java: needs merge
xxx.xml: needs merge解决办法一:git reset --merge
git reset --merge
是一种新的模式,其工作方式类似于git checkout
交换机分支的方式 ,在切换到另一个提交时进行本地更改.- 回退到merge之前
解决办法二:进行add commit操作
然后再次git checkout dev
⚠️执行了stash相关操作后,切换分支之前需要将当前分支未添加到工作区或暂存区的代码作添加或隐藏操作
否则报错:
error: Your local changes to the following files would be overwritten by checkout: src/main/java/com/qiandao/juc/stash.java Please commit your changes or stash them before you switch branches.
原文链接:https://blog.csdn.net/stone_yw/article/details/80795669
应用场景:
1 当正在dev分支上开发某个项目,这时项目中出现一个bug,需要紧急修复,但是正在开发的内容只是完成一半,还不想提交,这时可以用git stash命令将修改的内容保存至堆栈区,然后顺利切换到hotfix分支进行bug修复,修复完成后,再次切回到dev分支,从堆栈中恢复刚刚保存的内容。
2 由于疏忽,本应该在dev分支开发的内容,却在master上进行了开发,需要重新切回到dev分支上进行开发,可以用git stash将内容保存至堆栈中,切回到dev分支后,再次恢复内容即可。
总的来说,git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中,后续可以在某个分支上恢复出堆栈中的内容。这也就是说,stash中的内容不仅仅可以恢复到原先开发的分支,也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容,也就是说没有提交的内容都会保存至堆栈中。
能够将所有未提交的修改(工作区和暂存区)保存至堆栈中,用于后续恢复当前工作目录。
作用等同于git stash,区别是可以加一些注释,如下:
git stash的效果:
stash@{0}: WIP on master: b2f489c second
git stash save “test1”的效果:
stash@{0}: On master: test1
查看当前stash中的内容
将当前stash中的内容弹出,并应用到当前分支对应的工作目录上。
注:该命令将堆栈中最近保存的内容删除(栈是先进后出)
顺序执行git stash save “test1”和git stash save “test2”命令,效果如下:
$ git stash list
stash@{0}: On master: test2
stash@{1}: On master: test1
$ git stash pop
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: src/main/java/com/wy/StringTest.java
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (afc530377eacd4e80552d7ab1dad7234edf0145d)
$ git stash list
stash@{0}: On master: test1
可见,test2的stash是首先pop出来的。
如果从stash中恢复的内容和当前目录中的内容发生了冲突,也就是说,恢复的内容和当前目录修改了同一行的数据,那么会提示报错,需要解决冲突,可以通过创建新的分支来解决冲突。
将堆栈中的内容应用到当前目录,不同于git stash pop,该命令不会将内容从堆栈中删除,也就说该命令能够将堆栈的内容多次应用到工作目录中,适应于多个分支的情况。
$ git stash apply
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: src/main/java/com/wy/StringTest.java
no changes added to commit (use "git add" and/or "git commit -a")
$ git stash list
stash@{0}: On master: test2
stash@{1}: On master: test1
堆栈中的内容并没有删除。
可以使用git stash apply + stash名字(如stash@{1})指定恢复哪个stash到当前的工作目录。
从堆栈中移除某个指定的stash
清除堆栈中的所有内容
查看堆栈中最新保存的stash和当前目录的差异。
$ git stash show
src/main/java/com/wy/StringTest.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
git stash show stash@{1}查看指定的stash和当前目录差异。
通过 git stash show -p 查看详细的不同:
同样,通过git stash show stash@{1} -p查看指定的stash的差异内容。
从最新的stash创建分支。
应用场景:当储藏了部分工作,暂时不去理会,继续在当前分支进行开发,后续想将stash中的内容恢复到当前工作目录时,如果是针对同一个文件的修改(即便不是同行数据),那么可能会发生冲突,恢复失败,这里通过创建新的分支来解决。可以用于解决stash中的内容和当前目录的内容发生冲突的情景。 发生冲突时,需手动解决冲突。
融合多次commit提交,效果:
git rebase -i HEAD~~~
或者git rebase -i HEAD~3
变基合并代码
master上有一个新提交M,feature上有两个新提交C和D
此时切换到feature分支上,执行如下命令,相当于是想要把master分支合并到feature分支(这一步的场景就可以类比为我们在自己的分支feature上开发了一段时间了,准备从主干master上拉一下最新改动)
git checkout feature
git rebase master
//这两条命令等价于git rebase master feature
下图为变基后的提交节点图,解释一下其工作原理:
实际操作
将test02分支上push的代码合并到dev上:
git switch test02
git rebase dev
git switch dev
git merge test02
合并其他分支到当前分支
git checkout dev
git merge test
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
git add .
git commit -m "merge合并"
git push origin dev
直接创建:git tag <name>
创建带备注的标签:git tag -a <name> commitID -m <"message">
---
git tag v1.0
git tag v2.0
指定标签:git push origin <name>
所有标签:git push origin --tags
---
git push origin v1.0
git push origin v2.0
git tag -d <name>
---
git tag -d v1.0
git push origin :refs/tags/<name>
---
git push origin :refs/tags/v1.0
git show