Git
git的安装git部分(待补充)_baidu_41553551的博客-CSDN博客
git精简版整理https://blog.csdn.net/baidu_41553551/article/details/120935358
目录
Git出现There is no tracking information for the current branch提示
在使用tag后有时候commit出现异常 fatal: could not lookup commit del bug
版本库
版本库是一个仓库,这个仓库的所有文件都可以被git管理,但只能追踪文本文件的改动,对于图片、视频这种二进制文件,git只能追踪图片的大小变化,无法追踪改变了什么,还有就是word,work也是二进制格式,因此也无法进行追踪具体变化。
通过进行追踪改动,可以在将来对某个时刻进行还原
linux下创建版本库
下面内容,先创建一个目录,进入这个目录,查看目录的路径,将这个目录创建为版本库
mkdir learngit
cd ./learngit
pwd
git init
window下创建版本库
mkdir gitstore
cd learngit
pwd
git init
大体上一样,除了win下绝对路径要加c或者d等盘卷
初始化版本库后会生成.git文件,ls不显示,需要用ls -ah命令来显示
这个文件是用来跟踪和管理版本库的
把文件添加到版本库
前提:文件要在版本库或者版本库的子目录里面
如果在版本库外面会报错
在版本库里面新建一个new1.md文件
1、添加这个文件
git add new1.md
2、为这一个行为加个备注
git commit -m "add a new file"
linux下一样的操作
需要设置邮箱,做法在最上面的链接里面
修改文件再提交
将new1.md修改一下,然后查看状态
git status
git diff
解释:diff --git a/new1.md b/new1.md
表示的是这两个文件进行比较
index e316866..0daba04 表示的是两个文件的哈希值
100644表示的是普通文件的644权限
+表示的添加,-代表的删除
如果是更新的话则是删除了重新加
放到仓库里 git add "new1.md"
提交备注 git commit -m "update new1.md"
diff是different的缩写,是查看发生了哪些改变
status是查看仓库的状态
然后再查看状态
git status
查看提交日志
git log
马赛克标去的是姓名和邮箱
简化输出信息 git log --pretty=oneline
前面一大串是版本号,为什么这么长,就是为了防止冲突,为了独一无二。后面是commit的备注
版本回退
新建了一个文件,第一次新建了文件,第二次增加了aaa,第三次增加了bbb,第四次增加了cccc
回退到某一个版本
git reset --hard 版本号
回退到上一版本
HEAD代表当前版本,HEAD^代表上个版本,HEAD^^代表上上个版本
git reset --hard HEAD^
发现回退成功,到了增加bbb的那个版本里面
但是查看版本号发现没有了ccc的那一个版本
如果想要再回到ccc的版本
第一种方法就是查看历史消息
使用前几个hash值去回复
第二种方法是使用git reflog,根据id返回具体的版本
总结
到哪个版本是git reset --hard 版本号
查看以前的版本号是 git log或者git log --pretty==oneline
看未来的版本可以通过git reflog
工作区和版本区和暂存区
工作区就是一个文件夹
版本区
这些日后再更新 可以参考
Git整理(二):工作区和暂存区的介绍_zhouym_的博客-CSDN博客_git暂存区和工作区
修改
如果修改文件后使用git add命令将工作区的修改放入到暂存区,这时候如果再在工作区里面修改,修改完成后使用git commit命令并不会保存第二次的修改只会保存第一次的修改
撤销修改
修改还在工作区内
使用
git checkout -- "文件名称"
回到和版本库一样的状态
已经将内容提交到暂存区
使用git reset head "文件名"将文件从暂存区返回到工作区
如果还想要还原,使用上段撤销命令
内容提交到master
使用版本回退,看上述内容
总结
修改仅在工作区
使用 git check out -- 文件名 进行撤销到与版本库一样的内容(--与文件有空格)
修改加到了暂存区
使用git reset head 文件名 将文件回撤到工作区,如果还想撤销使用上述命令
也就是有两步
修改到了master
使用版本回退
删除文件与找回文件
删除文件
手动删除文件后,需要在版本库中删除
git rm "文件名"
git commit -m remove "文件名"
找回文件
误删文件找回(前提是以前提交到版本库里了)
使用
git checkout -- 文件名
这里文件名没有引号
远程仓库
这是你的仓库,为了识别是你推送的,所以需要进行身份验证,许多 Git 服务器都使用 SSH 公钥进行认证,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
新建密钥
ssh-keygen -t rsa -C "自己的邮箱"
一路回车
可以打开上图的地址
id_rsa是私钥,id_rsa.pub是公钥
把公钥加进github
title随便起名
然后增加成功
现在github可以确定你的身份了,下面开始操作
在github添加远程库
新建仓库
在github上新建一个仓库
关联
https和ssh都可以关联,下面是地址
现在使用ssh进行关联
注意到下面已经给了命令了
在本地仓库里面打开ssh,输入
完成关联,关联后,远程库的名字就是origin
推送
将本地库的内容全部推送到github上
git push -u origin master
上面出现了一个警告,这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入yes回车即可。
打开github,发现已经推送完成
所以,以后只要在本地存到版本库里,然后用
git push origin master
就可以提交到推送到github上了
就可以在远程库看到内容
删除远程库
这里指的是解除与远程库的绑定,如果需要真正删除远程库,需要到github上操作
解除绑定,先用git remote -v 查看远程库的信息
然后根据名字删除,比如删除origin
如果还想关联,找到地址
remote,这里我们换个名 originGit
总结
添加远程库的步骤为:
1、新建仓库,得到仓库的地址
2、通过[git remote add origin 地址]完成关联绑定 第一次绑定后 用git push -u origin master将master的所有分支全部推送过去
3、以后在本地修改完成后,提交到本地版本库,然后使用命令[git push origin master]推送到远程库
关闭与远程库的绑定步骤为:
1、git remote -v 查看本地仓库与远程仓库的绑定信息
2、git remote rm 远程库的名字 然后关闭绑定
从远程仓库克隆
克隆自己的项目
新建一个仓库
本地新建一个文件夹,进入文件夹git初始化
找到github上仓库的地址
输入命令 git clone [地址]
文件已经克隆完成
克隆他人项目
这里尝试使用https,但是发现报错。但换成http就可以了,当然使用ssh也可以
完成
但其实如果在本地不初始化仓库,直接克隆也是可以的,下面这个是随便的一个文件夹
总结
克隆需要知道克隆的地址
然后本地初始化一个仓库,git clone 地址完成克隆
https有时不能用,可以换换http,但这俩都不如ssh快
分支管理
master指向主分支,head指向当前分支,仅有一个分支的时候,head指向master
如果新建一个分支dev,再把head指向dev,可以理解成你的工作区指向了dev,指向的意义在于,对工作区的修改和提交就是针对dev分支
比如提交一次后,dev指针将向前移动一步,而master指针不变
如果dev完成了工作,合并到master的最快办法就是将master指针直接指向dev的提交
然后把dev指针删除(适用于单人的,多人协作的时候往往自己一个工作区,提交的时候仅提交不删除自己的工作区)
实战
创建dev分支
git checkout -b dev
这里注意的是加上-b表示创建并切换
相当于下面两条命令
git branch dev
git checkout dev
使用git branch查看当前分支,此命令会列出所有分支,当前分支前面会列出*号
然后修改一个文件,比如删除一个文件,然后提交
现在dev分支工作已经完成,切换到master分支
git checkout master
此版本下文件存在
然后把dev分支的工作成果合并到master分支上
git merge dev
可以发现new3.txt文件被删除
删除分支
然后删除dev分支,-d是delete的意思
git branch -d dev
强行删除分支
将放弃dev上产生的任何修改
git branch -D dev
然后查看当前存在的分支,发现仅剩master
但是前面撤销更改的时候用的是git checkout --<文件名>,这里用git checkout <分支名>会有点歧义,因此最新版本是用git switch -c dev来创建,用git switch <分支>来切换分支
总结
git switch -c <分支名> 创建并切换分支
git switch <分支名> 切换分支
git branch 查看分支,*是当前分支
git branch -d <分支名> 删除分支
冲突
在master新建一个dev分支,然后在此分支上向new4.txt添加一行数据
回到master分支,然后同样在此分支上向new4.txt添加一行数据
然后合并分支,发现冲突
使用git status查看冲突文件
找到冲突文件,打开那个文件
然后修改为我们想要的
提交
使用命令查看分支合并情况
git log --graph --pretty=oneline --abbrev-commit
没冲突的直接合并,有冲突的解决后,master分支改变为合并之后的样子,但是此时的dev分支依然保持自身的样子,并没有因为合并而产生变化。
合并操作( merge )只对对当前所在分支产生影响;无论是否存在冲突,合并之后,dev分支都不会发生变化。
总结
合并有冲突将在文件内有显示
git merge <分支名> 将分支名的修改合并到本分区内
git status 查看发生冲突的文件名 ,然后打开文件,会显示冲突的内容,按照自己的想法去修改内容(在本分支内,我最大,我愿意怎么改就怎么改,发生冲突,按我的意愿去修改文件)
合并操作( merge )只对对当前所在分支产生影响
分支管理策略
分支就是一个指针,删除分支就是把那个指针删了,相当于该分支不存在
比如我们上面在master上与dev上的进行合并了,然后删除了dev指针,这时候如果我们看历史信息,就会发现没有合并的历史内容
这是由于git在合并分区的时候会用Fast forward模式,如果要禁用这种模式,就能从分支历史上看出分支信息
下面思路是这样的,新建一个dev1分支,然后dev1分支添加一个文件,在master分支上将dev1分支的内容合并,然后删除dev1分支。验证在禁用Fast forword模式下是否会保留分支信息。
合并
git merge --no-ff -m "合并禁用默认" dev1
未删除dev1时
删除dev1后,依旧存在分支合并的内容
团队合作
master是非常稳定的,仅用来发布新版本,干活一般都在dev上面,每个人都有自己的分支,然后将自己的修改放到dev上面。
总结
在合并分支的时候使用git merge --no-ff -m "禁用默认Fast forward" <分支名>
将会留下历史合并信息,不会因为删除分支而丢掉历史合并信息
保留现场
使用命令 git stash
在这里我发现一个问题,如果一个工作区发生了修改还没有提交,那么在此基础上以本分支新建一个分支,那么分支将会继承主分支的工作区,暂存区和版本区
本图是新分支的状态,继承了前分支的所有
在master新建了一个分支dev,我在dev上增加了一个文件,这时候master出现了一个bug,需要修改。
这时候使用git stash保存现场
需要在master分支上修复,就从master创建临时分支dev1,修改完bug,在master上合并
总结
保存现场git stash
修改master分支上的bug,在master新建一个分支去修改,修改完成后再从master上和并
然后删除那个分支
回到自己的分支,git stash list查看保存现场的列表,将最上面的弹出来git stash pop
或者使用git stash list查看保存的内容,然后用git stash apply stash@{0}得到具体的某个现场
修改bug
在master上新建一个存在bug的文件,将其加入版本库里面
在issue_01分支里面,我删除那个bug
回到master里面合并那个分支
在master里面bug已经被修复
但是在dev里面bug没有被修复
使用git log --pretty=oneline找到日志 (错,找不到)
应该看issue_01当时向自己的版本库提交的代码,这个代码指明了这次提交的修改
在dev里面抓取这一次的修改
git cherry-pick <提交的hash值>
这里的提交是提交时显示的hash值,并非master合并分支,合并分支并没有显示合并分支的hash值
结果bug被修复
总结
bug是在master上,那么dev是从master上复制的,那么dev上也会有这个bug,在这期间,是用issue_01提交的修改,那么就可以只看那一次的修改,
将某一次的修改加入到我这里面git cherry-pick <提交产生的提价hash值>
这个hash并非在合并分支时产生的,而是在提交修改时产生的
多人协作
查看远程库的信息
如果没有推送权限,就看不到push的地址
创建分支
git branch <分支名>
推送分支
git push origin <远程库的分支名>
抓取分支
git clone
新建一个本地仓库,初始化一下,然后把远程库内容下载进来
使用git branch发现为空,这个原因可以看文章的最后面
我放弃了,官网文档上依旧是checkout -b
以后还是用checkout -b 比较好
推送
内容看下面
克隆远程库到本地的一个新分支
从头再来
此时在dev上修改 可以时不时的push到远端
创建与谁的关联就只能更新谁的,比如下面dev只关联了远程库的dev,想要更新master发现更新不了(错误)
本命令 如果本地分支名和远程分支名一样,那么就可以直接省略部分内容,比如本地dev要推到远程库的dev,就可以直接写成git push <远程主机名> dev
git push <远程主机名> <本地分支名>:<远程分支名>
为远程新建分支
本句是推送指定的分支,如果分支不存在那么就会新建一个
git push <远程主机名> <本地分支名>:<远程分支名>
向远程库推送冲突
如下图,dev和issue是从master中分离出来的,分别进行自己的工作,然后dev先进行了提交,那么此时issue是否还能提交?
结果
解决办法就是先pull下来,然后在本地合并,合并完成后再push
git pull也失败了,可以按照提示进行操作
git branch --set-upstream-to=<远程关联名>/<远程分支名> 本地分支
然后再pull一下
填入要填的信息
然后如果有冲突的文件,处理一下,具体形式往上翻
然后push
总结
初始化一个仓库 git init
建立与远程库的关联 git remote add <关联名> <远程库的地址>
查看关联 git remote -v
拉取远程库的项目 git pull (第一次git pull会报错,可以按照它提示的操作进行)
1、 如果要存放项目的分支还没有建立 git pull <关联名> <自己本地的分支(还未建立)>
执行后会为本地自动新建分支
2、 如果存放项目的分支建立了,那么执行
git branch --set-upstream-to=<关联名>/<远程库分支> <本地分支>
将修改投放到远程库
首先本地要commit,然后尝试直接推送到远程库
git push <远程主机名> <本地分支名>:<远程分支名>,远程分支名不存在则新建,可以随意指定
如果分支名相同,可以省略成 git push <远程主机名> <分支名>
如果push发生冲突,先pull(git pull 需要提前绑定追踪关系,就是上面的2)下来,解决完冲突,然后提交
打标签
git log --pretty=oneline --abbrev-commit
给某次修改bug的提交命名标签
某个分支修改bug且提交完成后,会生成一个commit的id
然后对此id加上标签
然后在某个分支里面,仅cherry-pick这个标签就可以
发现一个问题
如果不使用cherry-pick将会merge那个修改bug分支commit后的全部内容
如果某个分支加上了标签,那么其他分支同样会加上标签,但是只对于相同的内容,比如master更新到v3.0,但是dev里面仅仅更新到v2.0,那么dev里面就不会显示v3.0,但是可以通过v3.0进行合并
git tag <标签名> 将会对本分支的现在内容加上标签
git tag 查看所有标签
git log --pretty=oneline --abbrev-commit 查看历史的commit id
git tag v0.9 <commit id> 为历史commit添加标签(别的分支可以仅仅merge这一个提交)
git show <tagname> 查看具体标签内容
git tag -d <标签名> 删除标签名
git push <远程关联名> --tags 一次性推送全部尚未推送到远程的本地标签
删除远程标签
先删除本地的标签 git tag -d <标签名>
再删除远端的标签 git push origin :refs/tags/<标签名>
gitee的使用
Git报错解决:git@gitee.com: Permission denied (publickey). - 尚码园
一些错误
Git出现There is no tracking information for the current branch提示
pull函数并不知道要拉谁,因此可以直接指定,比如指定远程库的master
git pull origin master
另一种就是指定设置上拉谁,再去pull
git branch --set-upstream-to=<远程库>/<远程库的分支> <本地分支>
新建仓库发现分支为空的原因
Git 中的分支,其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。因此分支的出现必须先有commit的提交,从而产生有了一个指向最后一次提交对象的 master 分支
在使用tag后有时候commit出现异常 fatal: could not lookup commit del bug
先git commit提交,不加提交信息 ,然后会弹出一个文件,从里面添加注释就可以
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战