考考你的 Git 掌握情况

.什么是Git

1. Git 是分布式版本控制系统（DVCS）。它可以跟踪文件的更改，并允许你恢复到任何特定版本的更改。
2. 与 SVN 等其他版本控制系统（VCS）相比，其分布式架构具有许多优势，一个主要优点是它不依赖于中央服务器来存储项目文件的所有版本。
3. 每个开发人员都可以“克隆”我在图中用“Local repository”标注的存储库的副本，并且在他的硬盘驱动器上具有项目的完整历史记录，因此当服务器中断时，你需要的所有恢复数据都在你队友的本地 Git 存储库中。
4. 还有一个中央云存储库，开发人员可以向其提交更改，并与其他团队成员进行共享，如图所示，所有协作者都在提交更改“远程存储库”。

.Git和SVN有什么区别？

1. Git 是一个分布式的版本控制工具，SVN 是集中版本控制工具
2. Git 属于第3代版本控制工具，SVN 则属于第2代版本控制工具
3. Git 客户端可以在其本地系统上克隆整个存储库，SVN 的版本历史记录存储在服务器端存储库中
4. Git 即使离线也可以提交，SVN 只允许在线提交和回滚
5. Git 的Push/pull 操作更快，而 SVN Push/pull 操作较慢
6. Git 工程可以用 commit 自动共享，但 SVN 没有任何东西自动共享

. 如何在Git中创建存储库？

要创建存储库，先为项目创建一个目录（如果该目录不存在），然后运行命令 git init。通过运行此命令，将在项目的目录中创建 .git 目录。

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

新增文件的命令：git add file 或者 git add .
提交文件的命令：git commit –m 或者 git commit –a
查看工作区状况：git status –s
拉取合并远程分支的操作：git fetch/git merge 或者 git pull
查看提交记录命令：git reflog

.在 Git 中提交的命令是什么？

用于写入提交的命令是 git commit -a
通过在命令行上加 -a , 指示 git 提交已修改的所有被跟踪文件的新内容。
如果第一次提交新文件，可以在 git commit -a 之前先 git add <file>

.什么是 Git 复刻（fork）？复刻（fork）、分支（branch）和克隆（clone）之间有什么区别？

复刻（fork）: 是对存储仓库（repository）进行的远程的、服务器端的拷贝，从源头上就有所区别。
克隆（clone）: 不是复刻，克隆是个对某个远程仓库的本地拷贝。克隆时，实际上是拷贝整个源存储仓库，包括所有历史记录和分支。
分支（branch）: 是一种机制，用于处理单一存储仓库中的变更，并最终目的是用于与其他部分代码合并。

.拉取请求（pull request） 和 分支（branch） 之间有什么区别？

分支（branch）是代码的一个独立版本。
拉取请求（pull request）是当有人用仓库，建立了自己的分支，做了些修改并合并到该分支（把自己修改应用到别人的代码仓库）。

. git pull 和 git fetch 之间有什么区别？

单来说，git pull 是 git fetch + git merge。
当你使用 pull，Git 会试着自动为你完成工作。它是上下文（工作环境）敏感的，所以 Git 会把所有拉取的提交合并到你当前处理的分支中。pull 则是 自动合并提交而没有让你复查的过程。如果你没有细心管理你的分支，你可能会频繁遇到冲突。
当你 fetch，Git 会收集目标分支中的所有不存在的提交，并将这些提交存储到本地仓库中。但 Git 不会把这些提交合并到当前分支中。这种处理逻辑在当你需要保持仓库更新，在更新文件时又希望处理可能中断的事情时，这将非常实用。而将提交合并到主分支中，则该使用 merge。

. 描述一下你所使用的分支策略？

1. 功能分支（Feature branching）
   要素分支模型将特定要素的所有更改保留在分支内。当通过自动化测试对功能进行全面测试和验证时，该分支将合并到主服务器中。
2. 任务分支（Task branching）
   在此模型中，每个任务都在其自己的分支上实现，任务键包含在分支名称中。很容易看出哪个代码实现了哪个任务，只需在分支名称中查找任务键。
3. 发布分支（Release branching）
   一旦开发分支获得了足够的发布功能，你就可以克隆该分支来形成发布分支。创建该分支将会启动下一个发布周期，所以在此之后不能再添加任何新功能，只有错误修复，文档生成和其他面向发布的任务应该包含在此分支中。一旦准备好发布，该版本将合并到主服务器并标记版本号。此外，它还应该再将自发布以来已经取得的进展合并回开发分支。

. 分支是否已合并为 master，你可以通过什么手段知道？

git branch –merged 它列出了已合并到当前分支的分支。
git branch –no-merged 它列出了尚未合并的分支。

.新建一个 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 执行推送的操作，完成本地分支向远程分支的同步

.使用过 git merge 和 git rebase吗？它们之间有什么区别？

简单的说 git merge 和 git rebase 都是合并分支的命令。
git merge branch 会把 branch 分支的差异内容pull到本地，然后与本地分支的内容一并形成一个 committer 对象提交到主分支上，合并后的分支与主分支一致；
git rebase branch 会把 branch分支优先合并到主分支，然后把本地分支的 commit 放到主分支后面，合并后的分支就好像从合并后主分支又拉了一个分支一样，本地分支本身不会保留提交历史。

. 怎样将 N 次提交压缩成一次提交？

将N个提交压缩到单个提交中有两种方式：

1. 如果要从头开始编写新的提交消息，请使用以下命令：
   git reset –soft HEAD~N &&
git commit
2. 如果你想在新的提交消息中串联现有的提交消息，那么需要提取这些消息并将它们传给 git commit，可以这样：
   git reset –soft HEAD~N &&
git commit –edit -m"$(git log –format=%B –reverse .HEAD@{N})"

.在Git中，你如何还原已经 push 并公开的提交？

1. 删除或修复新提交中的错误文件，并将其推送到远程存储库。这是修复错误的最自然方式。对文件进行必要的修改后，将其提交到我将使用的远程存储库
   git commit -m "commit message
2. 创建一个新的提交，撤消在错误提交中所做的所有更改。可以使用命令：
   git revert <name of bad commit>

.如果本次提交误操作，如何撤销？

如果想撤销提交到索引区的文件，可以通过 git reset HEAD file；如果想撤销提交到本地仓库的文件，可以通过 git reset –soft HEAD^n 恢复当前分支的版本库至上一次提交的状态，索引区和工作空间不变更；可以通过 git reset –mixed HEAD^n 恢复当前分支的版本库和索引区至上一次提交的状态，工作区不变更；可以通过 git reset –hard HEAD^n 恢复当前分支的版本库、索引区和工作空间至上一次提交的状态。

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

首先确保本地仓库与远程之间是连同的。如果提交失败，则需要进行下面的命令进行连通：
git remote add origin 远程仓库地址
如果是第一次推送，则进行下面命令：
git push -u origin master
注意：-u 是指定origin为默认主分支
之后的提交，只需要下面的命令：
git push origin master

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

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

.什么是 Git 中的“裸存储库”？

Git 中的 “裸” 存储库只包含版本控制信息而没有工作文件（没有工作树），并且它不包含特殊的 .git 子目录。相反，它直接在主目录本身包含 .git 子目录中的所有内容，其中工作目录包括：

1. 一个 .git 子目录，其中包含你的仓库所有相关的 Git 修订历史记录。
2. 工作树，或签出的项目文件的副本。

.你使用过 git stash 命令吗？你一般什么情况下会使用它？

命令git stash 是把工作区修改的内容存储在栈区
以下几种情况会使用到它：

1. 解决冲突文件时，会先执行git stash，然后解决冲突；
2. 遇到紧急开发任务但目前任务不能提交时，会先执行git stash，然后进行紧急任务的开发，然后通过git stash pop取出栈区的内容继续开发；
3. 切换分支时，当前工作空间内容不能提交时，会先执行git stash再进行分支切换。

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

使用git log查看文件提交历史 Git log filename
使用git log查看分支提交历史 Git log branch file

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

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

.当GIT出现your-branch-is-ahead-of-origin-master-by-3-commits这一情况时，该如何处理？

Git commit
Git pull
Git push

.使用过git cherry-pick，有什么作用？

命令git cherry-pick可以把branch A的commit复制到branch B上。
在branch B上进行命令操作：

• 复制单个提交：git cherry-pick commitId
• 复制多个提交：git cherry-pick commitId1…commitId3
  注意：复制多个提交的命令不包含commitId1.

.如果代码出现 bug, 你们是如何解决的?

创建一个 bug 分支,然后进行bug处理,处理完毕后,合并到 review 分支,组长 review 成功后才能够合并到 master
合并完成之后删除 bug 分支
回到 dev 分支继续开发。

.git rebase的作用?

场景：在公司开发忘记提交到 github 托管，在家里又继续开发新的功能，
然后到公司昨天的代码跟你的新功能合并的时候可以用 git fecth ---> git rebase
那么他的提交记录就不会出现分叉,保持了提交记录的整洁.

.如何做代码的review？

创建 review 分支,然后再创建自己的个人分支,当你完成自己的业务逻辑的时候,
再合并到 review 分支.给组长做代码的 review

.如何查看分支提交的历史记录？查看某个文件的历史记录呢？

查看分支的提交历史记录：
命令 git log –number：表示查看当前分支前number个详细的提交历史记录；
命令 git log –number –pretty=oneline：在上个命令的基础上进行简化，只显示sha-1码和提交信息；
命令 git reflog –number:表示查看所有分支前number个简化的提交历史记录；
命令 git reflog –number –pretty=oneline：显示简化的信息历史信息；

如果要查看某文件的提交历史记录，直接在上面命令后面加上文件名即可。
注意：如果没有number则显示全部提交次数。

. 提交时发生冲突，你能解释冲突是如何产生的吗？你是如何解决的？

开发过程中，我们都有自己的特性分支，所以冲突发生的并不多，但也碰到过。诸如公共类的公共方法，我和别人同时修改同一个文件，他提交后我再提交就会报冲突的错误。
发生冲突，在IDE里面一般都是对比本地文件和远程分支的文件，然后把远程分支上文件的内容手工修改到本地文件，
然后再提交冲突的文件使其保证与远程分支的文件一致，这样才会消除冲突，然后再提交自己修改的部分。
特别要注意下，修改本地冲突文件使其与远程仓库的文件保持一致后，需要提交后才能消除冲突，否则无法继续提交。必要时可与同事交流，消除冲突。
发生冲突，也可以使用命令。

• 通过 git stash 命令，把工作区的修改提交到栈区，目的是保存工作区的修改；
• 通过 git pull 命令，拉取远程分支上的代码并合并到本地分支，目的是消除冲突；
• 通过 git stash pop 命令，把保存在栈区的修改部分合并到最新的工作空间中；

. 解释 Forking 工作流程的优点

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

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

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

. 之前项目中是使用的 Git Flow工作流程吗？它有什么好处？

GitFlow可以用来管理分支。GitFlow工作流中常用的分支有下面几类：

• master分支：最为稳定功能比较完整的随时可发布的代码，即代码开发完成，经过测试，没有明显的bug，才能合并到 master 中。请注意永远不要在 master 分支上直接开发和提交代码，以确保 master 上的代码一直可用；
• develop分支；用作平时开发的主分支，并一直存在，永远是功能最新最全的分支，包含所有要发布 到下一个 release 的代码，主要用于合并其他分支，比如 feature 分支； 如果修改代码，新建 feature 分支修改完再合并到 develop 分支。所有的 feature、release 分支都是从 develop 分支上拉的。
• feature分支；这个分支主要是用来开发新的功能，一旦开发完成，通过测试没问题（这个测试，测试新功能没问题），我们合并回develop 分支进入下一个 release
• release分支；用于发布准备的专门分支。当开发进行到一定程度，或者说快到了既定的发布日，可以发布时，建立一个 release 分支并指定版本号(可以在 finish 的时候添加)。开发人员可以对 release 分支上的代码进行集中测试和修改bug。（这个测试，测试新功能与已有的功能是否有冲突，兼容性）全部完成经过测试没有问题后，将 release 分支上的代码合并到 master 分支和 develop 分支
• hotfix分支；用于修复线上代码的bug。从 master 分支上拉。完成 hotfix 后，打上 tag 我们合并回 master 和 develop 分支。
  GitFlow主要工作流程
• 1.初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支
• 2.从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)
• 3.feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)；合并feature到develop , 可以选择删除当前feature , 也可以不删除。但当前feature就不可更改了，必须从release分支继续编码修改

• 4.从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG
• 5.release分支上线后 , 合并release分支到develop/master并推送；合并之后，可选删除当前release分支，若不删除，则当前release不可修改。线上有问题也必须从master拉取hotfix分支进行修改；
• 6.上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改；
• 7.hotfix通过测试上线后，合并hotfix分支到develop/master并推送；合并之后，可选删除当前hotfix ，若不删除，则当前hotfix不可修改，若补丁未修复，需要从master拉取新的hotfix继续修改；
• 8.当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上，即合并develop到当前feature分支；
• 9.当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上，即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)；
  GitFlow的好处
  为不同的分支分配一个明确的角色，并定义分支之间如何交互以及什么时间交互；可以帮助大型项目理清分支之间的关系，简化分支的复杂度。