Git相关知识点,要开始偷偷学习了

215 阅读11分钟

详情答案可以直接点击题目参看

1. 简单对比 git pull 和 git pull --rebase 的使用

参考答案:

git pull = git fetch + git merge git pull --rebase = git fetch + git rebase

解析:现在来看看git merge 和 git rebase 的区别

2. 什么时候使用“git rebase”代替“git merge”?

参考答案:你自己开发分支一直在做,然后你想把主线的修改合到你的分支上,做一次集成,这种情况就用 rebase 比较好,把你的提交都放在主线修改的头上

  1. rebase 会把你当前分支的 commit 放到公共分支的最后,所以叫做变基。就如同你从公共分支又重新拉出来这个分支一样。
  2. merge 会把公共分支和你当前的 commit 合并在一起,形成一个新的 commit 提交。

3. “拉取请求(pull request)”和“分支(branch)”之间有什么区别?

参考答案:

  • 分支(branch) 是代码的一个独立版本。

  • 拉取请求(pull request) 是当有人用仓库,建立了自己的分支,做了些修改并合并到该分支(把自己修改应用到别人的代码仓库)。

4. 什么是 Git 复刻(fork)?复刻(fork)、分支(branch)和克隆(clone)之间有什么区别?

参考答案:

  • 复刻(fork) 是对存储仓库(repository)进行的远程的、服务器端的拷贝,从源头上就有所区别。复刻实际上不是 Git 的范畴。它更像是个政治/社会概念。

  • 克隆(clone) 不是复刻,克隆是个对某个远程仓库的本地拷贝。克隆时,实际上是拷贝整个源存储仓库,包括所有历史记录和分支。

  • 分支(branch) 是一种机制,用于处理单一存储仓库中的变更,并最终目的是用于与其他部分代码合并。

5. 使用过 git cherry-pick,有什么作用?

参考答案:

命令 git cherry-pick 通常用于把特定提交从存储仓库的一个分支引入到其他分支中。常见的用途是从维护的分支到开发分支进行向前或回滚提交。 这与其他操作(例如:合并(merge)、变基(rebase))形成鲜明对比,后者通常是把许多提交应用到其他分支中。


git cherry-pick <commit-hash>

6. git 跟其他版本控制器有啥区别?

参考答案:

Git 比 svn 快,而且更加的流畅。

Git 在本地就可以使用,可以随便保存各种历史记录,不用担心污染服务器。

Git 在 branch 和 branch 之间切换非常简单。

Git 没有被 lock 不能 commit 的情况。

7. 我们在本地工程常会修改一些配置文件,这些文件不需要被提交,而我们又不想每次执行 git status 时都让这些文件显示出来,我们该如何操作?

参考答案:在 Git 工作区的跟目录下创建一个特殊的. gitignore 文件,然后把忽略的文件名编辑进去,Git 就会自动忽略这些文件。

8. 如何把本地仓库的内容推向一个空的远程仓库?

参考答案:

git init //生成. git 文件 git remote add origin 远程仓库地址 // 将本地和远程厂库关联起来 git add . git commit -m '提交信息' git push origin master // 将本地代码推送到库上

9. 提交时发生冲突,你能解释冲突是如何产生的吗?你是如何解决的?

参考答案:

1. 冲突是如何产生的

我们都知道,Git 的实现途径是 1 棵树。比如有一个节点树(point1),

  • 我们基于 point1 进行开发,开发出了结点 point2;

  • 我们基于 point1 进行开发,开发出了结点 point3;

    如果我们在 point2 和 point3 内操作了同一类元素,那么势必会导致冲突的存在。 主要的思想如下图 1 所示:

point1. js

function test() {
  console.log(a)
  var a = 1
}

人物甲 更新了版本 2 代码: poin2. js

function test() {
  console.log(a)
  var a = 2
}

人物乙 更新了版本 3 代码: poin3. js

function test() {
  console.log(a)
  var a = 3
}

场景如下,甲乙都是根据 point. js 文件进行了开发。甲开发出了版本 2,并且提交了代码;乙开发出了版本 3,也需要提交了代码,此时将会报错存在冲突。

为什么呢?因为甲开发完了版本,提交了版本之后,此时远端的代码已经是版本 2 点代码了,而乙是基于版本 1 进行的开发出了版本 3。所以,乙想要提交代码,势必要将自己的代码更新为版本 2 的代码,然后再进行提交,如果存在冲突则解决冲突后提交

2. 冲突是如何解决的

上面已经详细的说明了冲突时如何产生的,那么又该如何解决冲突呢?

解决冲突通常使用如下的步骤即可:

  • 情况 1 无冲突

先拉取远端的代码,更新本地代码。然后提交自己的更新代码即可。

  • 情况 2 有冲突

拉取远端代码。存在冲突,会报错。 此时我们需要将本地代码暂存起来 stash; 更新本地代码,将本地代码版本更新和远端的代码一致即可; 将暂存的代码合并到更新后的代码后,有冲突解决冲突(需要手动进行解决冲突); 提交解决冲突后的代码。

10. 列举工作中常用的几个 git 命令?

参考答案:

git init                     // 新建 git 代码库
git add                      // 添加指定文件到暂存区
git rm                       // 删除工作区文件,并且将这次删除放入暂存区
git commit -m [message]      // 提交暂存区到仓库区
git branch                   // 列出所有分支
git checkout -b [branch]     // 新建一个分支,并切换到该分支
git status                   // 显示有变更的文件

详细资料可以参考: 《常用 Git 命令清单》

11. git 提交代码时候写错 commit 信息后,如何重新设置 commit 信息?

参考答案:可以通过 git commit --amend 来对本次 commit 进行修改。

12. 说明新建一个 GIT 功能分支的步骤,提供每个步骤的指令,并对指令进行说明

参考答案:

git branch name 创建名字为 name 的 branch

git checkout xxx_dev 切换到名字为 xxx_dev 的分支

git pull 从远程分支拉取代码到本地分支

git checkout -b main_furture_xxx 创建并切换到 main_furture_xxx

git push origin main_furture_xxx 执行推送的操作,完成本地分支向远程分支的同步

13. 说明 git 合并的两种方法以及区别

参考答案:

git 代码合并有两种:git Merge 和 git ReBase

Git Merge:这种合并方式是将两个分支的历史合并到一起,现在的分支不会被更改,它会比对双方不同的文件缓存下来,生成一个 commit,去 push。

Git ReBase:这种合并方法通常被称为“衍合”。他是提交修改历史,比对双方的 commit,然后找出不同的去缓存,然后去 push,修改 commit 历史。

14. 如何查看文件的提交历史和分支的提交历史

参考答案:

使用 git log 查看文件提交历史

git log filename

使用 git log 查看分支提交历史

git log branch file

15. 当 GIT 出现如下情况时,该如何处理?

your-branch-is-ahead-of-origin-master-by-3-commits

参考答案:

Git commit

Git pull

Git push

16. 如何从 git 中删除文件,而不将其从文件系统中删除?

参考答案:

如果你在 git add 过程中误操作,你最终会添加不想提交的文件。但是,git rm 则会把你的文件从你暂存区(索引)和文件系统(工作树)中删除,这可能不是你想要的。

换成 git reset 操作:


git reset filename          # or
echo filename >> .gitingore # add it to .gitignore to avoid re-adding it

上面意思是, git reset <paths>git add <paths> 的逆操作

17. 什么时候应使用 “git stash”?

参考答案:

git stash 命令把你未提交的修改(已暂存(staged)和未暂存的(unstaged))保存以供后续使用,以后就可以从工作副本中进行还原。

18. 你能解释下 Gitflow 工作流程吗?

参考答案:

Gitflow 工作流程使用两个并行的、长期运行的分支来记录项目的历史记录,分别是 master 和 develop 分支。

  • Master,随时准备发布线上版本的分支,其所有内容都是经过全面测试和核准的(生产就绪)。

Hotfix,维护(maintenance)或修复(hotfix)分支是用于给快速给生产版本修复打补丁的。修复(hotfix)分支很像发布(release)分支和功能(feature)分支,除非它们是基于 master 而不是 develop 分支。

  • Develop,是合并所有功能(feature)分支,并执行所有测试的分支。只有当所有内容都经过彻底检查和修复后,才能合并到 master 分支。

Feature,每个功能都应留在自己的分支中开发,可以推送到 develop 分支作为功能(feature)分支的父分支。

19. Git 中 HEAD、工作树和索引之间的区别?

参考答案:

  • 该工作树/工作目录/工作空间是你看到和编辑的(源)文件的目录树。
  • 该索引/中转区(staging area)是个在 /. git/index,单一的、庞大的二进制文件,该文件列出了当前分支中所有文件的 SHA1 检验和、时间戳和文件名,它不是个带有文件副本的目录。
  • HEAD 是当前检出分支的最后一次提交的引用/指针。

20. 解释 Forking 工作流程的优点?

参考答案:

  • Forking 工作流程 与其他流行的 Git 工作流程有着根本的区别。它不是用单个服务端仓库充当“中央”代码库,而是为每个开发者提供自己的服务端仓库。Forking 工作流程最常用于公共开源项目中。

  • Forking 工作流程的主要优点是可以汇集提交贡献,又无需每个开发者提交到一个中央仓库中,从而实现干净的项目历史记录。开发者可以推送(push)代码到自己的服务端仓库,而只有项目维护人员才能直接推送(push)代码到官方仓库中。

  • 当开发者准备发布本地提交时,他们的提交会推送到自己的公共仓库中,而不是官方仓库。然后他们向主仓库提交请求拉取(pull request),这会告知项目维护人员有可以集成的更新。

21. 我想丢弃本地未提交的变化(uncommitted changes)

参考答案:

git reset --hard HEAD^

22. 我意外的做了一次硬重置(hard reset),我想找回我的内容

参考答案:

如果你意外的做了 git reset --hard, 你通常能找回你的提交(commit), 因为 Git 对每件事都会有日志,且都会保存几天。

(main)$ git reflog

你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。 选择你想要回到的提交(commit)的 SHA,再重置一次:

(main)$ git reset --hard SHA1234

这样就完成了。

23. 我的提交信息(commit message)写错了

参考答案:如果你的提交信息(commit message)写错了且这次提交(commit)还没有推(push), 你可以通过下面的方法来修改提交信息(commit message):

git commit --amend --only -m 'fix: 新的提交信息'

24.git 与 svn 的区别在哪里?

参考答案:

git 和 svn 最大的区别在于 git 是分布式的,而 svn 是集中式的。因此我们不能再离线的情况下使用 svn。如果服务器
出现问题,我们就没有办法使用 svn 来提交我们的代码。

svn 中的分支是整个版本库的复制的一份完整目录,而 git 的分支是指针指向某次提交,因此 git 的分支创建更加开销更小
并且分支上的变化不会影响到其他人。svn 的分支变化会影响到所有的人。

svn 的指令相对于 git 来说要简单一些,比 git 更容易上手。

详细资料可以参考: 《常见工作流比较》 《对比 Git 与 SVN,这篇讲的很易懂》 《GIT 与 SVN 世纪大战》 《Git 学习小记之分支原理》

25.git pull 和 git fetch 的区别

参考答案:

git fetch 只是将远程仓库的变化下载下来,并没有和本地分支合并。

git pull 会将远程仓库的变化下载下来,并和当前分支合并。

《详解 git pull 和 git fetch 的区别》

26.git rebase 和 git merge 的区别

参考答案:

git merge 和 git rebase 都是用于分支合并,关键在 commit 记录的处理上不同。

git merge 会新建一个新的 commit 对象,然后两个分支以前的 commit 记录都指向这个新 commit 记录。这种方法会
保留之前每个分支的 commit 历史。

git rebase 会先找到两个分支的第一个共同的 commit 祖先记录,然后将提取当前分支这之后的所有 commit 记录,然后
将这个 commit 记录添加到目标分支的最新提交后面。经过这个合并后,两个分支合并后的 commit 记录就变为了线性的记
录了。

《git rebase 和 git merge 的区别》 《git merge 与 git rebase 的区别》