git
[TOC]
git正则删除多个分支
|
|
git重命名包后还原
对于文件重命名时 不能对文件名直接修改
|
|
运行 git mv
就相当于运行了下面三条命令:
|
|
- 此时需要放弃缓存中的文件
|
|
参考:https://www.jianshu.com/p/b74ee1f4135f
- 清理未被track的文件或者文件目录
|
|
参考:https://www.jianshu.com/p/36a5c137a6d2
git合并某分支某次commit到另一个分支
将新分支dev2的一次提交,合并到dev1中
1、切到分支dev2
|
|
2、切换分支到dev1
|
|
上面结束之后,如果不想合并可以用 git cherry-pick –abort 放弃本次合并,否则直接push到远程库
push到远程git仓库
|
|
在本地删除远程分支
比较科学的practice:
|
|
將本地local
分支的代碼推送到遠程的local
分支,前面的test
就是指遠程倉庫的名字。第一个local
是本地分支的名字,第二个local
是远程分支的名字。名字不一定是lcoal,其它名字都可以的。
平时不太科学,但是能够work的practice:
|
|
这里运行git push
时候省略了一些参数。通常我们只有一个远程repo,所以就默认推送到了远程的origin
这个地方。分支的话,就是推送远当前分支到远程分支,如果远程分支上没有当前分支,还需要我们设定远程分支的upstream
。
- 如果没有设定远程仓库的名字,就默认推送当前分支绑定的远程分支,如果没有绑定的远程分支,则会报错。
- 如果没有设定分支名字,则自动推送当前分支到远程repo中同名的分支中去。
奇怪的操作,在本地删除远程分支:
通常我们删除远程的分支是在git的服务器端(如gitlab的网页,github的网页)进行的,实际实际上我们也可用通过推送一个空白的分支到某一个远程分支,实现删除某一个远程分支的目的。
|
|
参考:https://zhuanlan.zhihu.com/p/83793718
git reset
https://blog.csdn.net/qq_36431213/article/details/78858848
https://www.cnblogs.com/yaozhongxiao/p/3811130.html
git pull
在公司团队中写完代码就要提交到git上面,因为多人合作,先要将远端的代码pull更新到本地。往往这时候因为大家对同一个文件同一个地方做了操作,导致pull代码冲突发生,工程崩溃。提示错误信息如下:
|
|
这个提示意思就是说更新下来的内容和本地修改的内容有冲突,先提交你改变的内容或者先将你本地修改的内容暂时存起来。 下面我们就分几步解决处理这个pull冲突问题.
1.存储本地修改的内容
2.pull内容
3.还原备份暂存的代码
|
|
stash@{0}是你刚刚备份存储的标记 这时候系统会提示类似以下的信息:
|
|
这个提示内容意思就是系统自动合并修改的内容,但是当中会有冲突,需要解决其中的冲突。
4.解决文件中的冲突内容
打开上面提示的冲突文件,会看到类似的内容:
其中Updated upstream和=======之间的内容是从远端pull下来的代码,=======和Stashed changes之间的内容则是你本地修改的内容。这时候,需要你修改决定留下哪些需要的内容。
最后,解决完冲突,就可以正常git提交了。
git checkout
大体上两个用处:
- 切换或者新建分支
- 将暂存区或者指定commit内容覆盖到工作区。
从暂存区检出到工作区(如果暂存区没有该文件则再从版本库中还原),直接使用git checkout命令会将工作区的文件都覆盖,等价于放弃工作区的更改,当然如果文件没有trace则不会变化
如果你在commit的层面使用
check out
而非分支层面,HEAD的内容将会是一个commit哈希而非引用。这就是为什么Git能获悉它处在独立的状态的原因。多数情况,HEAD仅仅是一个你可以直接使用的引用。其他仅仅在使用Git内部工作的底层脚本时才会用到。
mac上git gui查看分支历史报没有gitk
There are two ways to fix this:
- Unix Way (simple and recommended)
- Homebrew Way
1. Unix Way: In 4 simple steps
- Execute
which git
in the terminal to know the location of yourgit
executable. Open that directory & locategitk
inside thebin
folder. Copy the path — typically/usr/local/git/bin
- Edit your
~/.bash_profile
to add the location of localgit
&gitk
in the paths or, simply copy-pasta from the sample written below.
Sample bash_profile
:
|
|
If you don’t have a bash_profile
want to learn how to create one, then click here.
- This step is relevant if you’re using El Capitan or higher & you run into an unknown color name “lime” error. Locate
gitk
executable (typically at/usr/local/bin/gitk
), take a backup & open it in a text editor. Find all occurences oflime
in the file & replace them with"#99FF00"
. - Reload bash:
source ~/.bash_profile
Now, run gitk
代码回滚
|
|
关于回滚,一般步骤是
- 使用 git log 命令,查看分支提交历史,确认需要回退的版本
- 使用 git reset 或者 git revert 命令,进行版本回退
- 使用 git push 命令,推送至远程分支(必须!!否则只能本地回退)
这里就重点说一下 git reset 和 git revert 的区别
举个例子,比如在master分支,有以下提交历史(PS:该示例出自这篇文章):
|
|
git revert
在使用git管理代码过程中,很多人应该遇到过一些场景:我已经提交了commit信息,但是我想反悔,不想提交了这个信息,或者公共分支上我提交了commit信息,别人也提交了commit,但是我的commit的代码有些问题,想撤回来不提交。
这种情况下有很多的方式来解决,无非是操作多少和风险的大小而已,比如:
- 公共分支上找到不同分支的父节点,reset以后才重新提交,但是当commit信息混合到一起后,你想找都commit信息都困难。
- 还有一种相对省事的方法你在自己的分支上把不要的都干掉后重新提交,但是如果是上线时候,这样风险也很大。
- 当然还有其他的一些方式方法
还有一种相对简单的方式,那就是 revert 方式(反做撤销)。也就是这篇文章的主角。
git revert基础用法
基础语法
|
|
- 只会反做commit-id对应的内容,然后重新commit一个信息,不会影响其他的commit内容
反做多个commit-id
|
|
- 反做commit-idA到commit-idB之间的所有commit
- 注意:使用-n是应为revert后,需要重新提交一个commit信息,然后在推送。如果不使用-n,指令后会弹出编辑器用于编辑提交信息
冲突的相关操作
- 在git操作过程中,最不想看到的一种情况就是冲突,但是,冲突就是一个狗皮膏药,永远避免不了,revert也跑不了这个魔咒,那么我们改怎么处理这个情况
合并冲突后退出
|
|
- 当前的操作会回到指令执行之前的样子,相当于啥也没有干,回到原始的状态
合并后退出,但是保留变化
|
|
- 该指令会保留指令执行后的车祸现场
合并后解决冲突,继续操作
- 如果遇到冲突可以修改冲突,然后重新提交相关信息
|
|
总结
Git reset和git revert的区别
- git reset 是回滚到对应的commit-id,相当于是删除了commit-id以后的所有的提交,并且不会产生新的commit-id记录,如果要推送到远程服务器的话,需要强制推送-f
- git revert 是反做撤销其中的commit-id,然后重新生成一个commit-id。本身不会对其他的提交commit-id产生影响,如果要推送到远程服务器的话,就是普通的操作git push就好了
tag管理
Commitid不容易记住,能不能用一种比较独特的方式去记住每个版本?答:Commitid相当于IP,Tag相当于域名。
|
|
可以看到,master最新版本为第四次修改。
如果发现,在第四次修改有错误,需要回滚到第三次修改,就可以用reset命令来回退。
执行 git reset –hard 97ea0f9,这个时候,git的提交历史变为:
|
|
可以看到master当前指向97ea0f9这个版本,我们回到了第三次修改。
使用 reset 命令,Git 会把要回退版本之后提交的修改都删除掉。要从第四次修改回退到第一次修改,那么会删除第二、三、四次的修改。【注:这里并不是真正的物理删除】
那如果发现第三次修改有错误,想要恢复第三次修改,却要保留第四次修改呢?
这个时候就可以用revert命令:
|
|
Git提交历史会变成:
|
|
实际上,Git把第三次修改从提交中剔除(还原)了,还保留了第四次修改,并且产生了新的commit_id。
在实际生产环境中,代码是基于master分支发布到线上的,会有多人进行提交。可能会碰到自己或团队其他成员开发的某个功能在上线之后有Bug,需要及时做代码回滚的操作。
在确认要回滚的版本之后,如果别人没有最新提交,那么就可以直接用reset命令进行版本回退,否则,就可以考虑使用revert命令进行还原修改,不能影响到别人的提交。或者说,除非在非常有把握的情况下,否则不要使用reset强推。
gitignore
|
|
CRLF将被LF替换问题
解决步骤:
-
安装dos2unix
-
转换文件
-
使用说明:https://www.jianshu.com/p/d2e96b2ccab9
git合并冲突后回退
多人合作开发时,将feature合到dev产生冲突,是别人的需要别人去解决冲突,此时可以放弃这次merge让别人去解决即可
|
|
git stash用法总结
https://www.cnblogs.com/zndxall/archive/2018/09/04/9586088.html
常用git stash命令:
(1)git stash save “save message” : 执行存储时,添加备注,方便查找,只有git stash 也要可以的,但查找时不方便识别。
(2)git stash list :查看stash了哪些存储
(3)git stash show :显示做了哪些改动,默认show第一个存储,如果要显示其他存贮,后面加stash@{$num},比如第二个 git stash show stash@{1}
(4)git stash show -p : 显示第一个存储的改动,如果想显示其他存存储,命令:git stash show stash@{$num} -p ,比如第二个:git stash show stash@{1} -p
(5)git stash apply :应用某个存储,但不会把存储从存储列表中删除,默认使用第一个存储,即stash@{0},如果要使用其他个,git stash apply stash@{$num} , 比如第二个:git stash apply stash@{1}
(6)git stash pop :命令恢复之前缓存的工作目录,将缓存堆栈中的对应stash删除,并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0},如果要应用并删除其他stash,命令:git stash pop stash@{$num} ,比如应用并删除第二个:git stash pop stash@{1}
(7)git stash drop stash@{$num} :丢弃stash@{$num}存储,从列表中删除这个存储
(8)**git stash clear** :
删除所有缓存的stash
git撤销本地修改
|
|
mac安装git-gui
|
|
git rebase操作记录
|
|
git add 与 git commit -am
原文地址git add命令是个多功能命令,根据目标文件的状态不同,此命令的效果也不同:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等
我们需要用git add命令来跟踪新文件,但如果使用git commit -am可以省略使用git add命令将已跟踪文件放到暂存区的功能,但是不会对新文件起作用。
远程分支版本回退
- git clone 远程分支master
- git checkout 提交错误的分支
- git reflog
- 根据操作日志查看想要回退的版本号(或远程提交记录里的版本号)
- git reset –hard 需要回退到的版本号
- git push -f
upstream
建立分支与分支之间的流通道
git push -u和git branch –set-upstream-to指令之间的区别
git push -u origin mybranch1 相当于 git push origin mybranch1 + git branch –set-upstream-to=origin/mybranch1 mybranch1
- - depth 1
|
|
清空github仓库而不是删除重新创建
|
|
commit完成之后再修改沿用上次commit log
重新git add, commit改成git commit –amend, 这样就还是一条git log信息
反向忽略
|
|
参考:http://www.voidcn.com/article/p-dlwytwql-btn.html
Summary
本节摘取于微信公众号码农田小齐, 作者小齐本齐
CVCS和DVCS
-
集中化版本控制系统 Centralized Version Control Systems (CVCS), 比如CVS, Subversion, Perforce, etc.
这种模式相对本地版本控制系统是有所改进的,但是缺点也很明显,如果服务器宕机,那么轻则耽误工作、重则数据丢失。于是分布式版本控制系统应运而生。
-
分布式版本控制系统 Distributed Version Control Systems (DVCS), 比如:Git, Mercurial, Bazaar, etc. 分布式的版本控制系统会把代码仓库完整地镜像下来,这样任何一个服务器发生故障,都可以用其他的仓库来修复。
什么叫“把代码仓库完整地镜像下来” CVCS 每个版本存放的是当前版本与前一个版本的差异,因此也被称作基于差异的版本控制 (delta-based); Git 存储的是所有文件的一个快照 (snapshot),如果有的文件没有修改,那就只保留一个 reference 指向之前存储的文件。
更进一步,这种模式可以更方便的和不同公司的人进行同一项目的开发,因为两个远程代码仓库可以交互,这在之前的集中式系统中是无法做到的。
Git的数据模型
- 什么是快照 (snapshot) 首先我们来学两个 Git 中的术语:
- blob, 就是单个的文件;
- tree, 就是一个文件夹。
快照则是被追踪的最顶层的树。
比如我的“公众号”文件夹的这么一个结构:
那么一个快照就是追踪的“公众号”这颗树。
- 本地库的数据模型
Git 记录了每个快照的 parent,也就是当前这个文件夹的上一个版本。
那么快照的迭代更新的过程就可以表示为一个有向无环图。
每个快照其实都对应了一次 commit。
|
|
这就是 Git 的数据模型。 blob, tree, snapshot 其实都一样,它们在 Git 中都是对象,都可以被引用或者被搜索,会基于它们的 SHA-1 hash 进行寻址。
git cat-file -t: 查看每个 SHA-1 的类型; git cat-file -p: 查看每个对象的内容和简单的数据结构。
但是通过这个哈希值来搜索也太不方便了,毕竟这是一串 40 位的十六进制字符,就是第二部分 git log 里输出的那个编码。 因此,Git 还给了一个引用 reference。比如,我们常见的 HEAD 就是一个特殊的引用。本地库就是由 对象 和 引用 构成的,或者叫 Repositories. 在硬盘上,Git 只存储 对象 和 引用,所有的 Git 命令都对应提交一个快照。
远程分支、远程跟踪分支、跟踪分支
远程分支就是在远程仓库上的普通分支。远程跟踪分支是在本地的只读的记录远程分支状态的分支,其指向用户无法移动,当使用git fetch等指令时其指向会依照远程仓库自动移动。跟踪分支是从远程跟踪分支上生成的本地分支,跟踪分支提供了本地分支与远程分支更紧密的联系,可以看出本地分支与对应的远程分支的超前落后情况,也可以使用git pull 指令轻松的将远程分支拉取到对应的跟踪分支。
git命令
git reflog 显示单行log
git reset –hard xxx 三个区都同步,都跳到这个 xxx 的版本上。
git reset –soft xxx 工作区和暂存区不同步,本地仓库跳到这个版本
git reset –mixed xxx 暂存区同步
git pull = fetch + merge
git fetch 这个操作是将远程库的数据下载到本地库,但是工作区中的文件没有更新。
merge 是 git pull 默认的选项,合并其实还有另外一种方法:rebase,中文叫做变基。
git rebase
rebase 的作用更多的是来整合分叉的历史,可以将某个分支上的所有修改都移到另一分支上,就像是变了基底。
git help eg:git help pull