Git

git的安装git部分(待补充)_baidu_41553551的博客-CSDN博客

git精简版整理https://blog.csdn.net/baidu_41553551/article/details/120935358

目录

版本库

linux下创建版本库

 window下创建版本库

把文件添加到版本库

修改文件再提交

 版本回退

 总结

工作区和版本区和暂存区

 修改

 撤销修改

修改还在工作区内

已经将内容提交到暂存区

内容提交到master

总结

删除文件与找回文件

删除文件

 找回文件

远程仓库

新建密钥 

把公钥加进github

在github添加远程库

新建仓库

 关联

推送

删除远程库 

总结

从远程仓库克隆

克隆自己的项目

 克隆他人项目

总结

 分支管理

删除分支

 强行删除分支

总结

 冲突

总结

分支管理策略

总结 

 保留现场

总结 

修改bug 

总结

多人协作

推送 

克隆远程库到本地的一个新分支

为远程新建分支

向远程库推送冲突

总结

打标签

gitee的使用

一些错误

 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提交,不加提交信息 ,然后会弹出一个文件,从里面添加注释就可以

posted @   贪睡地蜗牛  阅读(379)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示