git知识点以及git常见错误_hint: 'git pull ...') before pushing again. hint:

git commit的文件在哪？

先来理解下 Git 工作区、暂存区和版本库概念：

工作区：就是你在电脑里能看到的目录。

版本库：工作区有一个隐藏目录.git，这个不算工作区，而是 Git 的版本库。

暂存区：英文叫 stage 或 index。一般存放在.git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。

下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系：

再根据上图来分析分析 add commit

• 图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage/index）也就是修改后add的目的地；
• 图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
• 图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。
• 当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
• 当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

所以我认为commit的文件就放在了.git内的object

删除git 中的大文件

git filter-branch --tree-filter ‘rm -f src/assets/images/xcsp.mp4’ --tag-name-filter cat – --all

将该文件从历史记录的所有 tree 中移除 删除git提交历史中的有关某个文件的记录

git rev-list --objects --all | grep 67d195986439772f1220d64c6466457357ca7457

查询大文件的文件名

push的时候没有出现输入用户名密码

请执行 git config --system --unset credential.helper 完了再输入用户名密码

撤销对远程仓库的push操作 git reset

• git log 查看版本号
• 执行git reset --soft/–hard <版本号> ，如 git reset --soft 9d8c980edacd71410ed655，重置至指定版本的提交，达到撤销提交的目的。(–soft 已commit但是未push的)
• 然后执行 git log 查看提交日志

可以使用HEAD指定版本号 HEAD^ 上一个版本就是HEAD^，上上一个版本就是HEAD^^,
当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100
1
2

HEAD^的意思是上一个版本，也可以写成HEAD~1

如果你进行了2次commit，想都撤回，可以使用HEAD~2 // 上两个版本
此时，已重置至指定版本的提交，log中已经没有了需要撤销的提交

git reset 命令分为两种： git reset –-soft 与 git reset –-hard ，区别是：

git reset –-soft 表示只是改变了HEAD的指向，本地代码不会变化，我们使用git status依然可以看到，同时也可以git commit提交。 // 这样就成功的撤销了 commit 记录，回退到了指定版本
注意，仅仅是撤回 commit 操作，您写的代码仍然保留。

git reset –-hard直接回改变本地源码，不仅仅指向变化了，代码也回到了那个版本时的代码。一定要慎用git reset –-hard HEAD^ 小心一天努力全无

执行 git push origin 分支名 –-force ，强制提交当前版本号。

查看github commit 记录，对应的commit记录也撤销了

git reflog 和git log区别

关于commit的参数

–mixed

意思是：不删除工作空间改动代码，撤销 commit，并且撤销 git add . 操作

这个为默认参数 git reset --mixed HEAD^ 和 git reset HEAD^ 效果是一样的。

–soft

不删除工作空间改动代码，撤销commit，不撤销git add .

–hard

删除工作空间改动代码，撤销commit，撤销git add .

注意完成这个操作后，就恢复到了上一次的commit状态。

如果commit注释写错了，只是想改一下注释，只需要：
git commit --amend

此时会进入默认vim编辑器，修改注释完毕后保存就好了。

Git 遇到“File name too long”问题

1. 在git的命令行界面（git bash）或者Terminal 中输入

git config --get core.longpaths

可以看到界面中是返回了“false”;

2. 接着我们就可以输入

git config core.longpaths true设置core.longpaths这个配置项为true。

如果还是不行，就输入

git config --global core.longpaths true

然后问题“File name too long”得到解决，git bash 中git config --get core.longpaths 的返回是true.

remote: HTTP Basic: Access denied

使用git时推送项目代码是出现问题“remote: HTTP Basic: Access denied”，弄了几分钟找到了好的办法，在此记录一下。
首先要检查一下git的用户名和邮箱要和远程仓库一致（免得又出现七七八八的问题），其次是保存了提交并把用户名和密码都输入看一下，还出现这个问题就要输入：git config --system --unset credential.helper 即可

git 推送更新出现错误： Updates were rejected because the remote contains work that you do

每次建立新的仓库，提交的时总会出现这样的错误，真是头疼，……

直接开始正题，git 提交的步骤：
\1. git init //初始化仓库

1. git add .(文件name) //添加文件到本地仓库
2. git commit -m “first commit” //添加文件描述信息
3. git remote add origin + 远程仓库地址 //链接远程仓库，创建主分支
4. git push -u origin master //把本地仓库的文件推送到远程仓库

提交之后就会出现以下错误

要想解决以上错误，只需要在4，5之间使用git pull origin master即可

正确步骤：
\1. git init //初始化仓库

1. git add .(文件name) //添加文件到本地仓库
2. git commit -m “first commit” //添加文件描述信息
3. git remote add origin + 远程仓库地址 //链接远程仓库，创建主分支
4. git pull origin master // 把本地仓库的变化连接到远程仓库主分支
5. git push -u origin master //把本地仓库的文件推送到远程仓库

OK
搞定！！

如果还是出错可以把git pull origin master换成git pull --rebase origin master，就把远程仓库的文件同步到本地，本地就多了readme文件了，就可以上传了

还是不行的话 使用强传 ：git push -f origin master

Updates were rejected because the tip of your current branch is behind

error: failed to push some refs to ‘https://gitee.com//*.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

出现这样的问题，应该是没有在本地修改文件和同步保存，而是直接在GITEE上面删除和修改文件导致的，导致文件不对等。那我们这里采用一个办法，直接确保是文件没有问题的，直接强行推送过去更新、
git push -f origin master

git pull --rebase origin master拉取远程文件

fatal: refusing to merge unrelated histories解决

今天本地创建了一个仓库（有README)，把本地仓库和Github上关联以后，发现git pull，git feach提醒fatal: refusing to merge unrelated histories

上网查到原因是两个分支是两个不同的版本，具有不同的提交历史

加一句

git pull origin master --allow-unrelated-histories
1

可以允许不相关历史提，强制合并，确实解决了这个问题，感谢网友

error: failed to push some refs to如何解决

在使用git推送过程中出现的错误，以及解决办法

常见的错误

报错内容基本都是error: failed to push some refsto‘远程仓库地址’。

导致产生原因

我们想把自己本地的某个项目关联到远程仓库并推送上去

操作

• 本地项目—>远程仓库—>本地关联远程—>推送最新代码
• 错误往往发现在最后一个步骤
  

根本原因

我们在创建仓库的时候，都会勾选“使用Reamdme文件初始化这个仓库”这个操作初识了一个README文件并配置添加了忽略文件。当点击创建仓库时，

它会帮我们做一次初始提交。于是我们的仓库就有了README.m和.gitignore文件，然后我们把本地项目关联到这个仓库，并把项目推送到仓库时，我们在关联本地与远程时，两端都是有内容的，但是这两份内容并没有联系，当我们推送到远程或者从远程拉取内容时，都会有没有被跟踪的内容，于是你看git报的详细错误中总是会让你先拉取再推送，但是拉取总是失败。

解决办法
方法一
对于error: failed to push some refsto‘远程仓库地址’
1 使用如下命令
git pull --rebase origin master

2 然后再进行上传:

git push -u origin master

推送成功

方法二

• 想要避免这种问题，就要保持创建的仓库是一个空仓库，什么都没有。

• 就是创建仓库的时候不要勾选“使用Readme文件初始化这个仓库”

• 然后克隆下来方便使用，下次要推送就直接可以推送上去了。

git fatal: branch ‘master‘ does not exist

问题重现

1. 先在一个空文件夹里右击，然后点击 git bash here
   

2. 输入下面命令

git init

1. 我们假设要关联一个远程分支 https://gitee.com/kaimo313/webgl-demo.git

执行下面命令

git remote add origin https://gitee.com/kaimo313/webgl-demo.git
1

1. 再执行拉取代码命令

git pull
1

不出意外就会报下面的提示

1. 输入提示的命令

git branch --set-upstream-to=origin/master master
1

然后就会提示出来这个问题 fatal: branch 'master' does not exist

原因

出现这个问题原因就是本地没有 master 分支导致的。

输入 git branch -a。发现只有远程分支。

解决

解决方式就是：输入 git checkout master。

出现 Already on ‘master’ ,Branch ‘master’ set up to track remote branch ‘master’ from ‘origin’.，说明已经切换到 master 上。

再次输入 git branch -a。发现已经有本地分支

在用 git branch -avvv 查看

• 【a：查看所有分支】
• 【v：每个分支的最后一个提交（commit）】
• 【vv：本地分支与远程分支的关联关系】
  

warning: LF will be replaced by CRLF in ** 的原因及解决办法

今天在使用git add 命令的时候，弹出了一个警告 warning: LF will be replaced by CRLF in ******（具体的一个文件）

原因
LF和CRLF其实都是换行符，但是不同的是，LF是linux和Unix系统的换行符，CRLF是window 系统的换行符。这就给跨平台的协作的项目带来了问题，保存文件到底是使用哪个标准呢？ git为了解决这个问题，提供了一个”换行符自动转换“的功能，并且这个功能是默认处于”自动模式“即开启状态的。
这个换行符自动转换会把自动把你代码里 与你当前操作系统不相同的换行的方式 转换成当前系统的换行方式（即LF和CRLF 之间的转换），这样一来，当你提交代码的时候，即使你没有修改过某个文件，也被git认为你修改过了，从而提示"LF will be replaced by CRLF in *****"

解决
最简单的一种办法就是把自动转换功能关掉即可。
输入命令 ：git config core.autocrlf false (仅对当前git仓库有效）
git config --global core.autocrlf false (全局有效，不设置推荐全局）

更换git 仓库地址

• git remote -v
• git remote remove origin
• git remote add origin xxx
• git pull
  

发现该分支未跟踪，之前我操作的方式是先去远程建立一个分支，然后使用git branch --set-upstream-to=origin/xxx xxx 来，然后再git pull，这样前提是远程需要一个分支，没有的话，如下

现在我们最**直接使用git push --set-upstream origin xxx** 来

git branch --set-upstream-to=origin/ jishiOnline

我们本地新建一个分支，然后完成工作任务后，git add . git commit之后，然后准备使用git pull 拉取远程代码,

控制台会出现这个：

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> jishiOnline
1
2
3
4
5
6
7
8
9

大致意思就是，你本地新建了一个分支，但是这个新建的分支并没有和远程的某个分支是关联的。（git正是由于这种关联，才可以git pull ，git push）。

git branch --set-upstream-to=origin/<branch> jishiOnline

origin/<branch> --> 代表远程的某个分支， 一般以 origin/，都代表远程。 那这个为啥叫origin呢？ 
origin就是一个名字，它是在你clone一个托管在Github上代码库时，git为你默认创建的指向这个远程代码库的标签，
如果 我们走的是 git init --> git remote add origin https://gitee.com/song-yazhou123/learn_vue_for_new2.git,
如上 origin 是我们添加远程 到本地，`默认`创建的指向这个远程代码库的`标签`
1
2
3
4
5
6

本地分支和远程分支建立关联的前提是，远程要存在这个分支：

远程先创建然后checkout 到本地。

git checkout -b dev origin/dev //check出远程dev分支到本地
其实执行了两步，先创建本地分支dev，然后迁出远程分支dev到本地分支dev
1
2

创建本地分支并push到远程

git checkout -b dev  //创建并check出dev分支
git push origin dev(本地):dev(远程)//推送本地分支到远程分支，没有自动创建远程分支 
1
2

``

git commit 提交的时候报错husky > pre-commit hook failed (add --no-verify to bypass)（解决办法）

这个问题是因为当你在终端输入git commit -m “XXX”,提交代码的时候,pre-commit(客户端)钩子，它会在Git键入提交信息前运行做代码风格检查。如果代码不符合相应规则，则报错，而它的检测规则就是根据.git/hooks/pre-commit文件里面的相关定义。查询了网上的解决办法，总结为以下三种解决方案，个人喜欢第三种：

1. 卸载husky。只要把项目的package.json文件中devDependencies节点下的husky库删掉，然后重新npm i 一次即可。或者直接在项目根目录下执行npm uninstall husky --save也可以，再次提交，自动化测试功能就屏蔽掉
2. 进入项目的.git文件夹(文件夹默认隐藏,可先设置显示或者命令ls查找),再进入hooks文件夹,删除pre-commit文件,重新git commit -m ‘xxx’ git push即可。
3. 将git commit -m “XXX” 改为 git commit --no-verify -m “XXX”

同一电脑配置多个git服务商

同一台电脑配置使用两个git（一般一个gitee，一个是公司搭建的git服务，或者一个gitee，一个github）的两种办法？

最常见的当然是使用 ssh 而不是使用 https来 拉取推送代码；还有另一种是结合git的 credential.helper 配置来实现。

使用 ssh的方法

前提

按照网上教程安装完毕git bash。

清空已设置的全局邮箱和用户名称

如果按教程已经设置完全局邮箱和用户名称，则按照以下指令清除：

git config --global --list //查看你之前是否设置
git config --global --unset user.name "你的名字" //删除之前的名字配置
git config --global --unset user.email "你的邮箱"//删除之前的名字配置
1
2
3

这一步待考证。 当一台电脑上需要管理多个git账户时，就不推荐使用邮箱登录的方式去使用git了，因为git全局只能有一个user.name和user.email。是不是因为不同的git服务器上（公司的自己的）一般的话，用户名和邮箱是不相同的

清除相关文件

首先在git bash中进入.ssh文件夹：

cd ~/.ssh
1

以两个账号为例，输入：

ssh-keygen -t rsa -C "person@mail.com"
ssh-keygen -t rsa -C "company@mail.com"
1
2

每输入一个都需要再依次输入文件名、密码、密码确认，文件名分别为id_rsa_person和id_rsa_company（可以自己定），密码我没输入直接回车。

一般来说.ssh文件夹下会出现四个文件：

部署SSH key

分别登录git账号，新增SSH Key并将公钥文件内容添加到对应的账号中。
执行ssh-agent让ssh识别新的私钥：

这一步也可以省略，可以放到下面的测试连接时候，添加识别ssh

ssh-agent -s	//启动agent
ssh-add ~/.ssh/id_rsa_person
ssh-add ~/.ssh/id_rsa_company
1
2
3

创建config文件并配置

继续在.ssh目录下创建config文件，在config文件中添加以下内容：

# github配置
Host github.com
    HostName github.com
	#Port 7002
    User songyazhou
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa_github
 
# gitee配置
#Host gitee.com
    #HostName gitee.com
    User  songyazhou
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa_gitee
1
2
3
4
5
6
7
8
9
10
11
12
13
14

这里说明一下配置各字段的含义:

Host myhost（这里是自定义的host简称，以后连接远程服务器就可以用命令ssh myhost）
HostName 主机名可用ip也可以是域名(如:github.com)
PreferredAuthentications   配置登录时用什么权限认证--可设为publickey,password publickey,keyboard-interactive等
IdentityFile 证书文件路径（如~/.ssh/id_rsa_*)
User 登录用户名(如：git)
1
2
3
4
5

每个账号单独配置一个Host，每个Host要取一个别名，一般为每个Host主要配置HostName和IdentityFile两个属性，配置完保存即可。
Host的名字可以自定义名字，不过这个会影响git相关命令，例如：Host mygithub 这样定义的话，使用命令git clone git@mygithub:PopFisher/AndroidRotateAnim.git，git@后面紧跟的名字改为mygithub

远程测试

输入以下命令进行测试：

ssh -T git@personName
1

首次使用需要确认并添加主机到本机SSH可信列表。若返回 Hi XXX! You've successfully authenticated, but Gitee.com does not provide shell access. 内容，则证明添加成功。(注意输入的是yes)

添加成功后，就可以使用SSH协议对仓库进行操作了。

为仓库设置局部的用户名和邮箱

cd到对应仓库中：

git config user.name "person_name" 
git config user.email "person_email"
这里为啥不全局设置？
1
2
3

执行相关git命令，如果发生与远程库的交互，则可以看到远程库的密匙由灰变绿。

使用credential.helper 方法

credential.helper 是git密码持久化的配置。

git在提交时每次都需要输入密码和账号信息，可以将账号和密码进行持久化存储，当git push的时候输入一次用户名和密码就会被记录，不需要每次输入，提高效率，进行一下配置：

git config --global credential.helper [mode]
这里的mode可以是<cache>，<store>和macos的<osxkeychain>以及windows的<wincred>值：
1
2

• 设置cache模式时，内置凭证系统把登录凭证信息保存在机器内存中一段时间，时间过后将被从内存中移除。一般是15分钟，可以在配置时添加参数去自定义–timeout 30000。
• 设置store模式后，内置凭证系统把登录凭证信息保留在硬盘中，并且只要不主动清除则会一直保留，没有失效时间，除非修改密码或主动取消该模式。不过该模式存在安全问题在于密码信息是用明文保存。
• 设置osxkeychain模式时，此模式下的凭证助手会对登录凭证信息进行加密处理并存储。该模式只能在Mac系统使用。
• 设置wincred模式时，该模式会对凭证信息处理放入到Windows凭据管理器中，但是还是可以获取用户信息。该模式只能在Windows操作系统中使用。

了解完credential.helper。我们如何使用呢？

这里我设置模式为store，然后和之前一样输入一次账户密码就文件 git.credentials就可以了保存我们的认证信息了。以后在git pull git push 就不用在输入密码了。

上图是window中 git.crenditials和.gitconfig的保存位置
篇外：
使用github，用户名和密码也确认正常还是会报错。遇到这种情况是因为github更改了验证规则导致的。解决方法如下：
github为什么要把密码换成token

如何删除持久化密码呢？

如何删除持久化存储呢，这时候就需要把以前记录过的信息都删掉。

1. 列出信息，查看持久化存储方式

git config --list | grep credential 
注意，一般在window的cmd是无法使用grep命令的，可以使用在 git bash 使用该命令，（git bash方便在windows下使用git命令的模拟终端（windows自带的cmd功能太弱），而linux、unix可以直接使用git。bash是shell的一种，在shell 中可以使用，因为linux操作系统中，我们就是使用shell。linux与shell区别看另一篇博客）
1
2

显示出：

credential.helper=osxkeychain # 第一种就是mac自带的钥匙串
或者
credential.helper=store # 第二种是文件存储地址在 ~/.git-credentials

2. 删除信息

第一种需要进入启动台->其他->钥匙串访问，搜索git相关删掉目标信息。

第二种需要通过vim修改~/.git-credentials文件，删除以下类似信息：

http://username:password@git.xxx.cn
https://xxxx:xxxx@github.com

3. 或者统一用这种方法移除设置。

   git config --global --unset credential.helper
   1