Git学习笔记(命令、实战、踩坑记录)

Git学习笔记(命令、实战、踩坑记录)

• 转载原文的地址

目录:

git常用命令

      查看git的配置
      设置用户名和邮箱
      创建仓库
      查看文件的状态
      忽略文件
      提交代码到暂存区
      提交暂存区代码到版本库
      远程仓库和本地仓库交互
      分支操作

git理论

      仓库是什么
      工作的流程
      git中对于分支提交是如何更新本地或者远程仓库的
      预防冲突的方式

绑定github或者码云的SSH公钥

      创建本地的SSH公钥
      将公钥信息添加到码云或者gitHub的账户中

使用IDEA进行Git操作

      git 中文件状态区分
      git中编辑版本控制文件的特殊记号
      和远程分支比较的日志如何查看
      和远程分支进行比较
      和本地修改历史进行比较
      快捷键补充
      如何查看git的分支日志

Git错误归纳(踩坑历史)

      拒绝合并不匹配的历史版本文件 This is usually caused by another repository pushing：refusing to merge unrelated histories
      push到远程仓库失败了 error: failed to push some refs to '[email protected]:
      由于未解决的冲突导致ide中pull和commit都不能执行
      关于ide中合并冲突中的策略使用ours和theirs是干嘛的还有merge和rebase的区别

git常用命令

---

1. 查看git的配置

---

返回目录

1.1 查看配置

git config -l

1.2 查看系统配置

git config --system --list

1.3 查看用户配置

git config --global --list

1.4 相关配置文件

系统级 --system

Git\etc\gitconfig

用户级，只是使用与当前登录的用户 --global

C:\Users\Administrator\ .gitconfig

---

2. 设置用户名和邮箱

---

返回目录

git config --global user.name "kuangshen"  #名称

git config --global user.email 24736743@qq.com   #邮箱

---

3. 创建仓库

---

返回目录

1.1 创建工作目录

工作目录（WorkSpace)一般就是你希望Git帮助你管理的文件夹，可以是你项目的目录，也可以是一个空目录，建议不要有中文。日常使用只要记住下图6个命令：

1.2 本地仓库的搭建

创建本地仓库的方法有两种：一种是创建全新的仓库，另一种是克隆远程仓库。

1.3 创建全新的仓库，需要用GIT管理的项目的根目录执行：

git init

执行后可以看到，仅仅在项目目录多出了一个.git目录，关于版本等的所有信息都在这个目录里面。

1.4 克隆远程仓库

另一种方式是克隆远程目录，由于是将远程服务器上的仓库完全镜像一份至本地！

# 克隆一个项目和它的整个代码历史(版本信息)
$ git clone [url] 

可以去 gitee 或者 github 上克隆测试

---

4. 查看文件的状态

---

返回目录

#查看指定文件状态
git status [filename]

#查看所有文件状态
git status

# git add .                  添加所有文件到暂存区
# git commit -m "消息内容"    提交暂存区中的内容到本地仓库 -m 提交信息

版本控制就是对文件的版本控制，要对文件进行修改、提交等操作，首先要知道文件当前在什么状态，不然可能会提交了现在还不想提交的文件，或者要提交的文件没提交上。

Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged.

Unmodify: 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件

Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改 !

Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified

---

5. 忽略文件

---

返回目录

#为注释
*.txt        #忽略所有 .txt结尾的文件,这样的话上传就不会被选中！
!lib.txt     #但lib.txt除外
/temp        #仅忽略项目根目录下的TODO文件,不包括其它目录temp
build/       #忽略build/目录下的所有文件
doc/*.txt    #会忽略 doc/notes.txt 但不包括 doc/server/arch.txt

有些时候我们不想把某些文件纳入版本控制中，比如数据库文件，临时文件，设计文件等

在主目录下建立".gitignore"文件，此文件有如下规则：

忽略文件中的空行或以井号（#）开始的行将会被忽略。

可以使用Linux通配符。例如：星号（*）代表任意多个字符，问号（？）代表一个字符，方括号（[abc]）代表可选字符范围，大括号（{string1,string2,...}）代表可选的字符串等。

如果名称的最前面有一个感叹号（!），表示例外规则，将不被忽略。

如果名称的最前面是一个路径分隔符（/），表示要忽略的文件在此目录下，而子目录中的文件不忽略。

如果名称的最后面是一个路径分隔符（/），表示要忽略的是此目录下该名称的子目录，而非文件（默认文件或目录都忽略）。

---

6. 提交代码到暂存区

---

返回目录

# 将一个修改后的文件添加到暂存区
git add readme.md

# gitadd其他用法

# 添加所有修改、删除或新建的文件到暂存区
git add .
# 添加所有以js结尾的文件到暂存区
git add *.js
# 添加所有修改、删除或新建的文件到暂存区
# 除了.开头的文件，比如 .gitignore
git add *
# git add --update 的缩写
# 如果再次修改了在暂存区中的文件，可以通过该命令进行更新
git add -u
# 作用与git add . 相同
git add -A

---

7. 提交暂存区代码到版本库

---

返回目录

# 提交暂存区的代码到版本库
git commit -m 'commit message'

# 如果你重新编辑了一些文件，添加到暂存区，想把这些修改合并到上一次提交
# 然后会出现一个编辑框，让你修改上次的提交信息
git commit --amend
# 如果不想修改上次的提交信息
git commit --amend --no-edit

---

8. 远程仓库和本地仓库交互

---

返回目录

# 将名为origin的远程版本库的master分支同步到本地的当前分支
git pull origin master

# git pull命令其实是如下两个命令的简写
git fetch origin master
git merge origin/master


## 同步本地版本库到远程仓库

# 将本地的提交同步给远程版本库
git push --set-upstream origin master

# 绑定默认提交的远程版本库
git push -u origin master
# 下次提交只需要使用git push就可以了
git push

补充一个暴力拉取操作，但是小心使用

git pull origin master --allow-unrelated-histories

---

9. 分支操作

---

返回目录

# 列出所有本地分支
git branch

# 列出所有远程分支
git branch -r

# 新建一个分支，但依然停留在当前分支
git branch [branch-name]

# 新建一个分支，并切换到该分支
git checkout -b [branch]

# 合并指定分支到当前分支
$ git merge [branch]

# 删除分支
$ git branch -d [branch-name]

# 删除远程分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]

简单示例

#1. 先创建feature分支，将手头的代码提交到feature分支上
git checkout -b feature
git add .
git commit -m 'feature branch commit'

#2. 切换回master分支，从master拉一个新的分支
git checkout master
git checkout -b Fix-Bug

#3. bug修改完毕后，提交代码到Fix-Bug分支
git add .
git commit -m 'fixed bug'

#4. 把修复了bug的代码merge到master分支
git checkout master #重新切换回master分支
git pull origin master #把同事提交的代码先更新到本地
git merge Fix-Bug
git push origin master #将merge的代码同步到线上，进行bug修复
git branch -d Fix-Bug #bug修复后将Fix-Bug分支删除

---

git理论

---

1. 仓库是什么

---

返回目录

Git本地有三个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)。如果在加上远程的git仓库(Remote Directory)就可以分为四个工作区域。文件在这四个区域之间的转换关系如下：

• Workspace：工作区，就是你平时存放项目代码的地方

• Index / Stage：暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息

• Repository：仓库区（或本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本

• Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

注意了，这三个仓库的本质就是head指向的版本，也就是你最新的版本。

• Directory：使用Git管理的一个目录，也就是一个仓库，包含我们的工作空间和Git的管理空间。

• WorkSpace：需要通过Git进行版本控制的目录和文件，这些目录和文件组成了工作空间。

• .git：存放Git管理信息的目录，初始化仓库的时候自动创建。

• Index/Stage：暂存区，或者叫待提交更新区，在提交进入repo之前，我们可以把所有的更新放在暂存区。

• Local Repo：本地仓库，一个存放在本地的版本库；HEAD会只是当前的开发分支（branch）。

• Stash：隐藏，是一个工作状态保存栈，用于保存/恢复WorkSpace中的临时状态。

---

2. 工作的流程

---

返回目录

１、在工作目录中添加、修改文件；

２、将需要进行版本管理的文件放入暂存区域；

３、将暂存区域的文件提交到git仓库。

因此，git管理的文件有三种状态：已修改（modified）,已暂存（staged）,已提交(committed)

---

3. git中对于分支提交是如何更新本地或者远程仓库的

---

返回目录

首先，本地仓库和远程仓库分别维护着自己的一个分支，本地为local，远程是remote。
接着，我们需要知道本地分支和远程分支通过什么来进行更新的，如果你明白了这一点，那么git的精髓你也就掌握了，分支的更新需要通过commit的历史记录的比较判断来更新，所有只要有不同的commit记录，那么不同分支之间的pull和push或者merge…操作就会通过这些不同的commit记录来对分支进行更新，所以你想要知道每一次进行不同分支之间的操作对那些文件进行了更新，那么你就需要围绕着commit提交来判断。

---

4. 预防冲突的方式

---

返回目录

1.1 首先我们要知道为什么会冲突

情况一：远程分支的冲突，因为有多个开发人员对同一文件进行了修改提交，并且最后这些commit记录最后都提交到了同一个分支上，那么这样子就导致了远程分支的冲突
情况二：本地分支的冲突，你修改了本地的文件或者远程的分支更新了文件，并且这个文件是同一个，那么在本地拉取远程分支的时候就会产生冲突

1.2 遇到冲突，该如何解决

情况一：你比较了解这些代码的情况，那么可以直接通过你的理解对代码的冲突进行合并。
情况二：你不太了解这些代码，并且这些代码不是你管理的代码，那么就参照远程开发人员的提交。

1.3 常用的预防冲突的方式

在公司中，我们每一天进行开发前的第一件事情就是先从我们的master或者其他的主要分支上先pull代码，保持和远程仓库的版本统一。接着才是我们正常的开发流程。这也是在多人协作项目中能够有效防止分支冲突的一种方法。

这个方法可以减少冲突的发生，原理是什么呢，其实就是一个非常普通的逻辑，你每一次pull代码，代表你和远程分支进行了一次同步，那么你本地就会多出那些更新的代码，那么你就知道了那些文件添加了、删除了、更改了，那么这个时候你也就知道了我可能不需要去添加这个文件、去修改某个文件、去删除某个文件了(比如说本来我想要添加一个StringUtils.java文件，但是和远程同步之后，发现其他开发人员写了这个StringUtils.java文件，那么我就不用去添加这个文件并且进行编码，也就不会再这个文件上产生冲突了)，这样子，你的提交的代码可能也就减少了，那么你对远程分支的提交更新也就少了。

---

绑定github或者码云的SSH公钥

---

1. 创建本地的SSH公钥

---

返回目录

# 进入 C:\Users\Administrator\.ssh 目录
# 生成公钥
ssh-keygen

---

2. 将公钥信息添加到码云或者gitHub的账户中

---

返回目录

码云配置参考

这里演示GitHub的配置

---

使用IDEA进行Git操作

返回目录

---

---

1. git 中文件状态区分

---

返回目录

绿色：代表文件保存到了暂存区，但是没有提交
蓝色：代表和远程仓库进行过同步
淡灰色：代表这个文件被删除了

---

2. git中编辑版本控制文件的特殊记号

---

返回目录

删除一行的标记 黑色箭头
增加一行的标记 绿色标记
修改一行的标记 蓝色标记

---

3. 和远程分支比较的日志如何查看

---

返回目录

直接通过颜色辨别
绿色是本地新添加的文件，并且远程分支上并没有这个文件
蓝色是远程和本地都包含的文件，可以进行文件之间的比较

---

4. 和远程分支进行比较

---

返回目录

---

5. 和本地修改历史进行比较

---

返回目录

---

6. 快捷键补充

---

返回目录

Alt + ` git快捷窗口打开
Alt + 9 查看git日志
Ctrl + K 提交commit
Ctrl + shift + k 推送push
Ctrl + shift + p 拉取代码 pull

---

7. 如何查看git的分支日志

---

返回目录

Git错误归纳(踩坑历史)

---

---

1. 拒绝合并不匹配的历史版本文件 This is usually caused by another repository pushing：refusing to merge unrelated histories

---

返回目录

暴力解决方案，如果你的仓库没有存放非常重要的信息(例如里面仅仅只用一些日志信息)，那么可以采用这种解决方案。否则就不要这样暴力的解决。

git pull origin master --allow-unrelated-histories

接下来你发推送本地版本信息到远程就可以了

git push

---

2. push到远程仓库失败了 error: failed to push some refs to '[email protected]:

---

返回目录

额外的错误提示：Updates were rejected because the tip of your current branch is behind

git pull --rebase origin master

提示了错误信息

error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 更新
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

我们根据提示信息进行下一步操作，也就是将你发生冲突的文件进行合并

git add README.md

接着进行更新

git rebase --continue

最后重新push你的文件到远程仓库

git push -u origin master

---

3. 由于未解决的冲突导致ide中pull和commit都不能执行

---

返回目录

参考博客

下面是比较暴力的解决方式

1.将本地的冲突文件冲掉，不仅需要reset到MERGE-HEAD或者HEAD,还需要--hard。没有后面的hard，不会冲掉本地工作区。只会冲掉stage区。

git reset --hard FETCH_HEAD

2.git pull就会成功。

---

4. 关于ide中合并冲突中的策略使用ours和theirs是干嘛的还有merge和rebase的区别

---

返回目录

参考博客

1.1 merge和rebase简单的总结

git merge会抽取两个分支上新增的提交()，并将其合并在一起，产生一个新的提交D，生成的D节点有两个父节点。其中在合并的过程中可能会发生冲突。

git rebase会以branch_a为参照，提取branch_b分支上的提交，将这些修改作用在branch_a分支上，最终结果不会产生新的提交节点。其中在将提取的修改作用在branch_a的过程中可能会发生冲突。

注意：但是我在idea中进行分支操作实践中并不是像理论中那样，结果如下

1.2 ours和theirs的简单结论

直接说结论，对于merge和rebase来说，这两个选项对应的分支正好是相反的。以上述示例项目为例。在使用 merge 时，ours指的是当前分支，即branch_a，theirs指的是要被合并的分支，即branch_b。而在 rebase 的过程中，theirs指的是当前分支，即branch_a，ours指向修改参考分支，即branch_b。