git config -l
git config --system --list
git config --global --list
git/etc/getconfig 为系统默认配置
c盘下用户/.gitconfig为本地配置
git config --global user.name "wxk666666"
git config --global ueser.email "[email protected]"
Git本地有三个工作区域:
若加上远程的
就可以分为四个工作区域
实际上本地的三个区域确切的说是git仓库中HEAD指向的版本
在文件夹中有隐藏的.git文件,其中index就是暂存区,HEAD指向目录
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZLGTAlvU-1644500900029)(E:/Note/typora-study-notes/NoteImage/image-20220117203852657.png)]
文件在这四个区域的转换关系如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zo1bDsn5-1644500900030)(E:/Note/image-20220117204206231.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZFkXh9e4-1644500900031)(E:/Note/typora-study-notes/NoteImage/image-20220117204206231.png)]
提交: -------git add files----> -------git commit-----> -----------git push-------->
{工作区} {暂存区} {资源区} {远程Git仓库}
<-------git pull--------- <-------git reset--------- <--------git checkout-----
创建本地仓库的方法有两种:创建全新的仓库,克隆远程仓库
1.创建全新的仓库,需要用Git管理的项目的根目录执行
#在当前目录新建一个Git代码库
$ git init
2.执行后可以看到,仅仅在项目目录多了一个.git目录,关于版本等信息都在里面
1.克隆远程目录
#克隆一个项目和它的整个代码历史
$git clone [url]
版本控制: 版本控制就是对文件的版本控制,要对文件进行修改,提交等操作,首先要知道文件当前在什么状态不然提交了现在还不想提交的文件,或者要提交的文件没提交上。
Untracked:未跟踪,此文件在文件夹中,但是并没有加入到git库中,不参与版本控制通过git add
状态变为staged。
Staged:暂存状态,执行git commit
则将修改同步到库中,这时库中的文件和本地的文件又变为一致,文件为Unmodify状态.执行git reset
HEAD filname 取消暂存,文件状态为Modified。
Unmodify:文件已经入库,未修改,即版本库中的文件快照内容与文件夹完全一致,这种类型的文件有两种去处,如果它被修改,而变为Modified,如果使用git rm
移出版本库 则成为Untracked文件
Modified:文件已修改,仅仅是修改,并没有进行其他的操作,这个文件也有两个去处 通过git add
可进入暂存Staged状态,使用git checkout
则丢弃修改过,返回到unmodify状态,这个git checkout
则即从库中取出文件覆盖当前修改。
#查看指定文件状态
git status [filename]
#查看所有文件状态
git status
#git add . 添加所有文件到暂存区
#git commit -m 提交暂存区内容到本地仓库
有时候我们不想把某些文件纳入版本控制中,比如数据库文件,临时文件,设计文件等。
在主目录下建立”.gitignore“文件,此文件有如下规则:
#为注释
*.txt #忽略所有以.txt结尾的文件,这样上传就不会被选中
!wxk.txt #但wxk.txt除外
/temp #仅仅忽略项目根目录下的TODO文件,不包括其他目录,即忽略根目录下的temp文件
build/ #忽略build/目录下的所有文件
doc/*.txt #会忽略doc/notes.txt 但不包括 doc/server/arch.txt,即忽略doc下任意名的txt文件
ssh-keygen
使用加密 ssh-keygen -t 加密算法
eg:
ssh-keygen -t rsa
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xJy4okfh-1644500900031)(E:/Note/typora-study-notes/NoteImage/image-20220118001103494.png)]
回车即可
若遇到
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qOGB7JXW-1644500900032)(E:/Note/typora-study-notes/NoteImage/image-20220118002048511.png)]
则在目录下创建.ssh文件夹后执行命令即可
成功:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AoJpkhFB-1644500900032)(E:/Note/typora-study-notes/NoteImage/image-20220118002220065.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8iizWMhY-1644500900032)(E:/Note/typora-study-notes/NoteImage/image-20220118002201652.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SWhiUGF7-1644500900033)(E:/Note/image-20220118002220065.png)]
pub:即public 公钥
不带则为私钥
使用pub即可,记事本打开
**密钥对:**在非对称加密技术中,有两种密钥,分为私钥和公钥,私钥是密钥对所有者持有,不可公布,公钥是密钥对持有者公布给他人的。
**公钥:**公钥用来给数据加密,用公钥加密的数据只能使用私钥解密
**私钥:**如上,用来解密公钥加密的数据。
**摘要:**对需要传输的文本,做一个HASH计算,一般采用SHA1,SHA2来获得
**签名:**使用私钥对需要传输的文本的摘要进行加密,得到的密文即被称为该次传输过程的签名。(看最下面的一部分就明白了)
签名验证:数据接收端,拿到传输文本,但是需要确认该文本是否就是发送发出的内容,中途是否曾经被篡改。因此拿自己持有的公钥对签名进行解密(密钥对中的一种密钥加密的数据必定能使用另一种密钥解密。),得到了文本的摘要,然后使用与发送方同样的HASH算法计算摘要值,再与解密得到的摘要做对比,发现二者完全一致,则说明文本没有被篡改过。
**加密:**是将数据资料加密,使得非法用户即使取得加密过的资料,也无法获取正确的资料内容,所以数据加密可以保护数据,防止监听攻击。其重点在于数据的安全性。
类似于平行宇宙,也就是多个版本,互不干扰,但是可以合并
dev为分支名
#列出所有本地分支
git branch
#列出所有远程分支
git branch -r
#新建一个分支,但是依旧停留在当前分支
git branch [branch-name]
#新建一个分支,并切换到该分支
git checkout -b [branch]
#切换分支
git checkout <branch name> #
git checkout -b dev origin/dev#此时切换的是远程的分支,记得一定要带远程的文件路径,不然无法切换,而是在本地创建develop
#合并指定分支到当前分支
git merge [branch]
将远程主机 origin 的 master 分支拉取过来,与本地的 brantest 分支合并。
git pull origin master:brantest
如果远程分支是与当前分支合并,则冒号后面的部分可以省略。
git pull origin feature-passwordF
#推送分支
git push origin dev
#删除分支
git branch -d [branch-name]
#删除远程分支
git push origin --delete [branch-name]
git branch -dr [remote/branch]
1、先建一个分支(所有的改动都是在分支上) git branch 分支名
2、切换到新建的分支 git checkout 分支名切换到新的分支
3、先提交代码到分支上 git add . git commit -m “”
4、先切换至主支上 git checkout master
5、然后合并分支 git merge 分支名字
6、合并完以后就push 最好先pull一次 然后 git push
7、切换到自己的分支 git merge 线上分支名称 /git checkout 分支
即一个文件在合并分支时在两个分支中都被修改了就会引起冲突,解决方法是我们可以修改冲突文件后重新提交!选中要保留两个分支中的其中一个以即可。选中要保留的master主分支应当非常稳定,用来发布新版本,一般情况下不允许在上面功作,工作一般情况下在新建的dev上工作,dev分支代码稳定后可以合并到主分支master上来
主分支 master 主分支,所有提供给用户使用的正式版本,都在这个主分支上发布
开发分支 dev 开发分支,永远是功能最新最全的分支
功能分支 feature- 新功能分支,某个功能点正在开发阶段
发布版本 release- 发布定期要上线的功能
修复分支 bug-* 修复线上代码的 bug