git笔记

coderwhy听课笔记

什么是集中式 分布式

集中式是将整个仓库放到服务器；分布式是每台电脑上都有对应的仓库，可以在本地提交，之后把本地的仓库同步到服务器的仓库里

git安装

除了能使用git命令，还安装了git bash,git GUI
git bash在CMD的基础上增加了一些新的命令与功能，可以执行linux命令，因此其实完全可以用git bash替代CMD

git GUI提供了图形化界面来运行git命令

如果经常使用vscode的话，可以在vscode配置一个git bash终端

git操作

git初始化和clone远程仓库

获取git仓库

• 新项目
  • git init
• 已存在的项目
  • git clone

克隆的如果是私有的仓库，需要输入用户名密码 或者配置ssh key才能成功

git两种状态

未跟踪状态，已跟踪状态
默认情况下，Git仓库下的文件没有添加到Git仓库管理中，需要通过add命令来操作

已跟踪状态

• staged： 暂缓(存)区/索引区(Index)中的文件状态 （git add以后，还没有添加到某一次提交里面 git log无法查看）并没有和任何提交联系在一起
• unmodified： commit命令，可以将staged中文件提交到git仓库
• modified： 修改了某个文件后，处于modified状态 ，需要重新添加到暂缓区里面

绿色方框这里都是有关本地的操作

上部分写了几种状态，那如果查看所处的状态呢 – git status

add以后 : changes可以被提交， 可以使用git rm --cached 去把文件在暂缓区里面移除掉

git rm --cached 相当于这个

add以后可以提交了

git忽略文件

有些文件不希望git来跟踪和管理，通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等;
在vue脚手架生成的文件，他长这个样子

git校验和(commit id) 日志和版本回退

每次提交里面都有这样一串东西， 这个是git校验和 是标识提交的标识符 ，是基于git中文件的内容或目录结构计算出来的

git log 可以查看commit id，作者，日期
如果想更美观一点 可以用 git log --pretty=oneline

git log --pretty=oneline --graph (多分支的时候有用)

版本回退 git reset
如果说当前head有个重大bug 想回退到以前的版本
可以通过HEAD来改变git目前的版本指向

git reflog 对回退版本的操作也做了记录

git远程仓库

可以使用第三方的Git服务器 如github, gitee, gitlab等 或在自己服务器搭建一个Git服务
gitlab不好注册，访问速度慢

很多公司都是用自己的服务器搭建 通过gitlab软件而不是gitlab服务器，可以在云服务器里面使用gitlab的功能

用gitlab搭的长这样

远程仓库创建和验证方式

gitee上创建一个私有远程仓库，需要把他克隆下来

有两个地址可供选择，一个https, 一个ssh
尝试https, 是需要输入用户名密码验证身份的，有权限才可以克隆 git credential
尝试ssh, 需要ssh密钥

http

因为http协议是无状态的连接，所以每个连接都需要用户名和密码,每次都要输入用户名密码，开发效率很低， git有一个凭证系统专门处理，

git credential选项

选项五可以用这个查看是否有开启 没有开启的话，每次都输入一遍用户名密码 非常麻烦

ssh密钥

在电脑上输入一串命令，生成一对公钥和私钥， 需要将公钥放到服务器
如果是通过ssh连接服务器的，那会自动读取私钥，把私钥携带到服务器，服务器拿到私钥和公钥进行匹配来进行验证，不需要用户名密码

三个回车后

去第一次回车时，提示保存的位置 ，这个文件里面就是公钥

拿到里面的东西，添加到gitee里面的 安全设置->ssh公钥
添加完之后，使用git clone ssh地址 就能成功了

远程仓库的添加和同步

克隆下来以后，执行git remote -v

如果本地已经有代码了，可以添加远程服务器， git remote add <shortname>(如origin) <url>
之后 git pull

其实最主要的还是add commit pull push

fetch和merge遇到的问题处理

问题一： 跟踪问题
问题二： merge问题
（如果本身是git clone下来的代码 就不会出现这个问题， git init创建会出现这个问题）

在某个文件夹里面已经有东西了，还没有交给git仓库来管理，可以通过git init来初始化一个本地仓库， 之后add commit 这样就添加到本地的仓库里了

这时候想和远程仓库建立连接

这时候执行git pull 拉取远程仓库的代码
报错了

虽然本地仓库和远程仓库通过git remote add命令建立了连接，但是不知道本地的哪个分支和远程的哪个分支建立连接，

可以使用git pull origin(哪一个远程仓库，因为刚刚add了origin) master(分支名)
每次都这样的话 有点麻烦 可以给当前本地的master分支设置一个上游分支，上游分支就是服务器里面的某一个分支，可以让他们两个之间建立关系， 上游分支又叫跟踪分支， 设置了上游分支，之后再进行git pull的时候，就可以自动从上游分支获取，不需要每次都指定origin master这些东西了

上游分支的设定：

执行完这个， 下次直接git pull就可以

还有一种做法 git branch --track dev origin/master

执行git pull的时候，还是会报错

git pull的本质是git fetch + git merge
git fetch是没有问题的，问题出在git merge
git merge的作用是 让当前的master分支去和另外一个分支进行合并
git merge后面不跟东西的情况下，默认合并的是上游分支 也可以git merge origin/master直接指定， 但直接指定也会报这个错误

来梳理一下，现在是想将本地的master分支和origin/master做一个合并，将远程代码合并到项目里面去，在过去git merge是可以实现的，虽然两个分支没有共同的基础（base）,本地的仓库提交历史和服务器提交历史没有相交的地方

现在如果想让两个没有祖先的分支进行合并，需要用git merge --allow-unrelated-histories, 这样就算没有共同祖先也可以进行合并

之后git push 可以将本地的master 放到远程的master里

远程仓库命令

push操作

把当前的master分支推送到远程的main分支

那如果写这个命令呢

这个意思是将当前的master分支推送到远程的master分支 git push origin master:master

那只执行git push呢, 想让他推送到上游分支，报错
这个和git配置有关系，可以配置git push的默认行为
默认的是这个

但是我想找的其实是上游的分支 那就可以这样配置

另外一个模式（当前分支：dev）: 找相同的远程分支，找不到就新建一个远程的分支， 而simple模式，找不到会报错

tag使用

某一次提交把阶段性的任务完成了，可以给提交打一个标签，方便之后做查找,做版本回退，一般项目比较重要的版本都会打一个tag

对某一个commit打tag

git的提交对象和底层原理

通过commit id可以找到一个文件 这个文件里面记录了tree, 通过tree找到一个文件，这个文件里面包含了依赖文件，

git init之后，会产生.git文件夹

1. 首先看里面的objects文件夹，git add .会把东西放到暂缓区里面，然后就会多出两个东西
   
   再点开
   
   里面到底放的什么？
   git cat-file -t 00d2 (d2为文件前两位 会自动去objects文件夹下面找)
   打印blob 为二进制的文件

git cat-file -p 00d2
打印文件内的内容
所以说这个时候，其实文件已经被存起来了

2. git commit
   这时候多出两个文件
   

看一下这两个文件里面有什么

这个eb5c其实就是校验和 也就是commit id

所以每一次提交 就是通过sha1和 找到5c2bxxx这个文件，
可以看到这个文件里面，还有一个叫tree, 对应465815xxxx

465815xx里面存的这个

如果想看master文件里面的内容 可以直接把文件拖到vscode

创建和切换多个分支和本质

现在有四次提交， 每次提交都会有一个commit对象， 四个提交会通过parent联系在一起，

master其实就是一个文件，这个文件指向最后一次提交，master分支是默认情况下git帮我们创建的分支，除了master分支，也可以自己创建更多的分支


git checkout / git switch 可以切换分支 git checkout -b dev 可以创建并切换过去

切换完之后

head指向谁 现在就处在哪个分支

现在切回到master, 之后修改内容 git add commit之后，会发生什么变化？

这个时候再checkout testing
head就会指向testing了

再testing分支下 修改代码，进行add, commit

这样就变成两条开发流程了

为什么使用分支

比如tag v1.0.0 已经发布上线了， 团队继续往后写代码，准备发布第二个版本的过程中，忽然发现第一个版本有bug, 需要某个人去修复bug, 就可以回到tag v1.0.0里面，在这个版本里面创建一个分支，叫hotfix

改完了 但是现在444 555都是有bug的 所以需要把hotfix分支的东西合并到master分支里面

演示一下操作
开发到333打一个tag ， 继续向后开发 开发到555
这时候反馈333上线后有bug， 现在要且回到333版本里面
git checkout -b hotfix 创建分支 修复完bug以后 再commit提交

修复完了 打上一个新的tag

那就可以再打包上线了

还要且回到master分支，master分支这时候还是有bug，要修复一下，得将hotfix里面修复好的代码合并到master分支里面，这就叫分支的合并
执行git merge hotfix

出现了冲突，代码就长这个样子

<<后面的head相当于master
<<< 到== 中的都是master分支的代码
===到>>>中的都是hotfix分支的代码

可以手动解决 把《《 == 》》都删掉
vscode就更加方便了 他会自动识别符号， 上面有几个按钮

然后add commit

这样这个"合并hotfix"的commit有两个parent

图结构




移除分支其实是把指针移除掉，提交并没有移除

提交历史还是长这样

git工作流

有重要版本了，就切到master里面，合并dev分支

topic是什么？ 新的主题。 比如正在开发网易云音乐项目， 突然我想加入视频播放的功能，有可能最终能实现 也可能实现不出来， 如果在dev开发，到最后发现做不出来，那我提交那么多东西根本没有意义，最后还得做回退。
所以再公司，可能就会有个topic分支，专门开发主题模块就行了，开发的好，就合并到dev里， 如果开发不出来，直接删掉分支就行了，不需要做额外的操作。


准备发布了 就创建release分支，测试测试的就是release的版本，测试测出来bug,就去修复这个bug，把修复好的版本 合到dev里面，还要合到master打上tag

git的远程分支

本地有master分支 远程有main分支
git remote add orgin xxxx地址
之后git fetch 把远程代码拉下来
这时候本地有两个分支 一个master， 一个origin/main
想让master和origin/main建立连接
git branch --set-upstream-to=origin/main 建立master的上游分支， 到现在为止，其实本地文件是没有变化的，
他们两个是没有共同祖先的 这个时候git merge origin/main 或者直接git merge 默认合并上游分支
会报错因为没有共同祖先 可以执行git merge --alow-unrelated-histories
git push 报错， 因为默认是simple模式 设置 git config push.default upstream
之后就可以git push了

因为本地的分支叫master，远程分支叫main, 把master push到main总感觉有点别扭，所以可以git checkout --track origin/main 会自动创建一个新的分支main 并跟踪origin/main分支， 名字一致了就不需要该push的simple模式了, 最好不要让名字不一样不然就很麻烦

本地新增一个分支 dev, 远程没有， 想让组员也在dev分支开发，是需要把分支推送到远程的，
直接git push （相当于git push origin dev:dev）报错

可以git push origin dev 这时候远程仓库也有dev分支了
也得设置上游分支

---

再设置上游分支就可以了

---

对于组员

会检查本地有没有develop分支，没有就会去远程仓库找有没有分支
再git branch

git checkout dev 相当于做了三部操作

1. 检查远程有没有dev分支
2. 创建本地的dev分支
3. 让dev分支跟踪origin/dev
   这样可以直接push 不用做其他配置

删除本地分支和远程分支命令不一样

git rebase , merge区别

假如目前有两个分支 feature, master
工作流（hotfix改成master）

现在做了merge合并以后

历史记录已经不是线性了

希望变成这种效果

这就要rebase来完成

首先要切换到feature分支里面， 不要再master分支操作！
feature里面执行git rebase master
原来bbb是feature的base, 现在是要用master指向的commit对象作为feature的base

这样master滞后了 可以切到master，git merge feature, master也指向最新的commit对象

其他

以前喜欢把主分支命名为master 现在逐渐改成main了 说是master有主人的意思 有种族歧视？

环境变量： 分为系统环境变量和用户环境变量
多用户概念：现代操作系统是多用户的，一个操作系统可以创建多个用户，如果有两个用户，那我配置的环境变量到底是给哪个用户配的呢，如果在系统环境变量里面配置，那就是给所有用户配置

git add . + git commit -m ‘’ === git commit -a -m ‘’

git凭证