经过这些问题有助于你快速了解学习 Git

做者：Duomly
译者：前端小智
来源：dev.to

点赞再看，养成习惯

本文 GitHub https://github.com/qq44924588... 上已经收录，更多往期高赞文章的分类，也整理了不少个人文档，和教程资料。欢迎Star和完善，你们面试能够参照考点复习，但愿咱们一块儿有点东西。

1. 你最喜欢的 Git 命令是什么

我的比较喜欢 git add -p. 这增长了“补丁模式”的变化，这是一个内置的命令行程序。它遍历了每一个更改，并要求确认是否要执行它们。

这个命令迫使我们放慢速度并检查更改文件。做为开发人员，我们有时经常急于提交，我本身也常常这样，作完运行 git add . 才发现把调试的代码也提交上去了。

2. 为何你更喜欢直接使用 git 命令

做为开发人员，我们也常用其它命令来作其它事情，也不差用 git 的命令来作事。

此外，git 命令也是很是短的，很是容易学习，而且使用命令能够了解 git 的工做流程，这样也间接改进了开发工做流程。

3. 如何使用 stage 命令

stage是add .的内置别名。

4.如何在分支中保存更改并 checkout 到其余分支

所以，可使用 git stash 临时存储更改或提交 WIP,目的是要有未修改前的环境。就我我的而言，我更喜欢使用 WIP 提交而不是 stash，由于它们更容易引用和共享。

WIP = Work in Progress

研发中的代码想存储起来，可是又避免研发中的代码被合并，开发就会建立一个WIP的分支

WIP MR

WIP MR 含义是 在工做过程当中的合并请求，是一个咱们在 GitLab 中避免 MR 在准备就绪前被合并的技术。只须要添加 WIP: 在 MR 的标题开头，它将不会被合并，除非你把 WIP: 删除。

5.何时使用 git stash

发现有一个类是多余的，想删掉它又担忧之后须要查看它的代码，想保存它但又不想增长一个脏的提交。这时就能够考虑 git stash。

6.如何使用 git 命令

对任何命令使用 --help选项，例如，git stash --help。

7. 什么是“ git flow”？

Git Flow 定义了一个项目发布的分支模型，为管理具备预约发布周期的大型项目提供了一个健壮的框架，是由 Vincent Driessen 提出的一个 git 操做流程标准、解决当分支过多时 , 如何有效快速管理这些分支。

8.什么是 GitHub flow ？

GitHub flow，顾名思义，就是 GitHub 所推崇的 Workflow。（千万不要理解成 GitHub 上才能用的 Workflow）, 基本上，GitHub Flow 是master/feature分支工做流程的品牌名称。

GitHub flow 的核心优点在于其流程带来的自动化可能性，可以作到其它流程没法实现的检查过程，并极大简化开发团队的体力劳动，真正发挥自身的价值。

你们都说简历没项目写，我就帮你们找了一个项目，还附赠【搭建教程】。

9.你更喜欢哪一种分支策略?

大多数 Git项目都是 “Git flow”。这些项目中只有少数须要这种策略，一般是由于它是版本化的软件。

master/feature 分支策略更易于管理，尤为是在刚入门时，若是须要，切换到 “git flow” 很是容易。

10. git open 命令是作啥用的

这是一个单独的命令，能够做为 npm 包使用。

11.当在其余分支中添加的文件仍然在工做分支中显示为未跟踪或修改时，如何重置分支

这一般是“工做索引”不干净时切换分支的结果。

在 git 中没有内置的方法来纠正这一点。一般经过确保提示符有一个 “status” 指示符并在每次更改分支时运行诸如 git status 之类的命令来避免这种状况。这些习惯会让我们尽早发现这些问题，这样就能够在新的分支上 stash 或 commit 这些更改。

12. 如何重命名分支?

git branch -m current-branch-name new-branch-name

13. 如何使用 cherry-pick

git cherry-pick [reference] 请记住，这是一个从新应用的命令，所以它将更改提交 SHA。

14. 若是从一个分支恢复(例如 HEAD~3)，是否能够再次返回到 HEAD(好比恢复上一次更新)

在这种状况下，经过运行 git reset --hard HEAD~1 当即撤消还原提交（即 HEAD 提交）。

15. 何时使用 git pull 和 git fetch？

git pull将下载提交到当前分支。记住，git pull其实是 fetch 和 merge 命令的组合。

git fetch将从远程获取最新的引用。

一个很好的类比是播客播放器或电子邮件客户端。我们可能会检索最新的播客或电子邮件(fetch)，但实际上还没有在本地下载播客或电子邮件附件(pull)。

16. 为何有时须要使用 --force 来强制提交更改

rebase 是一个能够从新提交的命令，它改变了 SHA1 hash。若是是这样，本地提交历史将再也不与其远程分支保持一致。

当这种状况发生时，push 会被拒绝。只有在被拒绝时，才应该考虑使用 git push --force。这样作将用本地提交历史覆盖远程提交历史。因此能够回过头来想一想，想一想为何要使用 --force。

17. 可使用分支合并多个分支，而后将该分支发送给 master 吗？

固然能够，在大多数 git 工做流下，分支一般会累积来自多个其余分支的更改,最终这些分支会被合并到主分支。

18. 应该从一个很是老的分支作一个 rebase 吗？

除非是无可奈何。

根据你的工做流，能够将旧的分支合并到主分支中。

若是你须要一个最新的分支，我更喜欢 rebase。它只提供更改且更清晰的历史记录，而不是来自其余分支或合并的提交。

然而，尽管老是可能的，可是使用 rebase 多是一个痛苦的过程，由于每次提交都要从新应用。这可能会致使多重冲突。若是是这样，我一般使用rebase --abort 并使用 merge 来一次性解决全部冲突。

19. 使用 rebase -i 时，squash 和 fixup 有什么区别

squash 和 fixup 结合两个提交。squash 暂停 rebase 进程，并容许我们调整提交的消息。fixup 自动使用来自第一次提交的消息。

20. 一般，当使用 master 从新创建功能分支时，对于每次提交都须要解决冲突？

是的。因为每次提交的更改都会在 rebase 期间从新应用，因此必须在冲突发生时解决它们。

这意味着在提交以前就已经有了提交冲突，若是没有正确地解决它，那么下面的许多提交也可能发生冲突。为了限制这一点，我常用 rebase -i 来压缩提交历史记录，以便更轻松地使用它。

若是许多提交之间仍然存在冲突，可使用 merge。

你们都说简历没项目写，我就帮你们找了一个项目，还附赠【搭建教程】。

21.在与 master 合并以前，有必要更新个人分支吗

根据你的工做流，能够将旧的分支合并到主分支中。若是你的工做流仅使用 "fast-forward"合并，那么有必要在合并以前更新你的分支。

Git fast forward 提交

多人协同开发，使用 Git 常常会看到警告信息包含术语：fast forward, 这是何义？

简单来讲就是提交到远程中心仓库的代码必须是按照时间顺序的。

好比 A 从中心仓库拿到代码后，对文件 f 进行了修改。而后 push 到中心仓库。

B 在 A 以前就拿到了中心仓库的代码，在 A push 成功以后也对 f 文件进行了修改。这个时候 B 也运行 push 命令推送代码。

会收到一个相似下面的信息：

chenshu@sloop2:~/work/189/appengine$ git pushTo 
ssh://csfreebird@10.112.18.189:29418/appengine.git ! [rejected]       
master -> master (non-fast-forward)error: failed to push some refs to 
'ssh://csfreebird@10.112.18.189:29418/appengine.git'To prevent you from losing 
history, non-fast-forward updates were rejectedMerge the remote changes (e.g. 'git 
pull') before pushing again.  See the'Note about fast-forwards' section of 'git push --help' for details.

提醒你非快进方式的更新被拒绝了，须要先从中心仓库pull到最新版本，merge后再 push.

fast forward 可以保证不会强制覆盖别人的代码，确保了多人协同开发。尽可能不要使用 non fast forward方法提交代码。

22. 须要使用 GitKraken 这种可视化工具吗

我比较喜欢用命令方式使用 git，由于这使我可以彻底控制管理变动，就像使用命令来改进个人开发过程同样。

固然，某些可视化操做(如管理分支和查看文件差别)在GUI中老是更好。我我的认为在合并过程当中在浏览器中查看这些内容就足够了。

23. 当提交已经被推送时，能够作一个 --amend 修改吗？

能够，git commit –amend 既能够对上次提交的内容进行修改，也能够修改提交说明。

24.在作迭代内容时，当完成一个小功能须要先拉一个 pull request 请求，仍是都作完这个迭代内容后在拉一个 pull request 请求

我们一般作法是，完成一个迭代的内容后在拉一个 pull request。然而，若是你某个任务上花了很长时间，先合并作的功能多是有益的。这样作能够防止对分支的依赖或过期，因此作完一个拉一个请求，仍是所有作完在拉一个请求，这决于你正在进行的更改的类型。

25. 在将分支合并到 master 以前，须要先建立一个 release 分支吗？

这在很大程度上取决于大家公司的部署过程。建立 release 分支对于将多个分支的工做分组在一块儿并将它们合并到主分支以前进行总体测试是有益的。

因为源分支保持独立和未合并，因此在最后的合并中拥有更大的灵活性。

26. 如何从 master 获取一些提交?比方说，我不想执行最后一次提交，而是进行一次 rebase。

假设 master 分支是我们的主分支，我们不但愿有选择地从它的历史记录中提取提交，这会之后引发冲突。

我们想要 merge 或 rebase 分支的全部更改。要从主分支以外的分支提取选择提交，可使用 git cherry-pick。

27. 如何在 git 终端配置颜色

默认状况 下git 是黑白的。

git config --global color.status auto 
git config --global color.diff auto 
git config --global color.branch auto 
git config --global color.interactive auto

配置以后，就有颜色了。

28. 有没有更好的命令来替代 git push -force ?

实际上，没有其余方法能够替代 git push—force。虽然这样，若是正确地使用 merge 或 rebase 更新分支，则无需使用 git push --force。

只有当你运行了更改本地提交历史的命令时，才应该使用 git push --force。

你们都说简历没项目写，我就帮你们找了一个项目，还附赠【搭建教程】。

29. 当我在 git rebase - 选择drop时，是否删除了与该提交相关的代码？

是的。要恢复这段代码，须要在 reflog 的 rebase 以前找到一个状态。

30. 如何自动跟踪远程分支

一般，当你 checkout 或建立分支时，Git 会自动设置分支跟踪。

若是没有，则能够在下一次使用如下命令进行更新时：git push -u remote-name branch-name。

或者可使用如下命令显式设置它：git branch --set-upstream-to = remote-name / branch-name

31. 在 rebase 分支以前更新分支，是一个好的习惯吗？

我认为是这样的，缘由很简单，用git rebase -i 组织或压缩提交，首先在更新过程当中提供更多的上下文。

32. 有没有一种方法能够将提交拆分为更多的提交（与 fixup/squash 相反）？

能够在rebase -i过程当中使用 exec 命令来尝试修改工做索引并拆分更改。还可使用 git reset 来撤消最近的提交，并将它们的更改放入工做索引中，而后将它们的更改分离到新的提交中。

33.有没有办法查看已修复的提交？

git log

查看日志，找到对应的修改记录，可是这种查找只能看到文件，而不是文件的内容。

git blame 文件名

查看这个文件的修改记录，默认显示整个文件，也能够经过参数 -L <start>,<end>来检查须要修改的某几行。

若是查看以前提交的内容可使用 git show commitId。

34. rebase --skip 做用是啥？

我们知道 rebase 的过程首先会产生 rebase 分支（master）的备份，放到（no branch ）临时分支中。再将支线分支（branch）的每一次提交修改，以补丁的形式，一个个的从新应用到主干分支上。这个过程是一个循环应用补丁的过程，期间只要补丁产生冲突，就会中止循环，等待手动解决冲突。这个冲突指的是上一个合并后版本与补丁之间的冲突。

git rebase --skip 命令，能够跳过某一次补丁（存在上一轮冲突的解决方案中，已经包含了这一轮的补丁内容，这样会使补丁无效，须要跳过），这个命令慎用。

你们都说简历没项目写，我就帮你们找了一个项目，还附赠【搭建教程】。

35. 如何删除远程分支？

可使用:git push origin:branch-name-to-remove 或使用 -d选项:git push -d origin someother -branch-2 来删除远程分支。

要删除对远程分支的本地引用，能够运行:git remote prune origin。

36. checkout 和 reset 有什么区别

这两个命令均可以用来撤销更改。checkout 可能更健壮，由于它不只容许撤消当前更改，并且还容许经过检索文件的旧版本撤消一组更改。

默认状况下，reset更适合于更改工做索引中更改的状态。所以，它实际上只处理当前的变化。

git checkout -- file；撤销对工做区修改；这个命令是以最新的存储时间节点（add和commit）为参照，覆盖工做区对应文件file；这个命令改变的是工做区。

git reset HEAD -- file；清空 add 命令向暂存区提交的关于 file 文件的修改（Ustage）；这个命令仅改变暂存区，并不改变工做区，这意味着在无任何其余操做的状况下，工做区中的实际文件同该命令运行以前无任何变化

37. 在正常的工做流程中应该避免使用哪些命令

一些可能会破坏历史记录的内容，例如：

git push origin master -f (千万不要这样作)
git revert
git cherry-pick (changes from master)

在正常的工做流程下，尽可能避免直接使用git merge，由于这一般是经过拉请求(pull requests)构建到流程中的。

38. 若是我有一个分支(B)指向另外一个分支(A)，而我又有另外一个分支(C)，它须要(A)和(B)及 mast 分支的代码，怎么个流程才能更新(C)？

这取决于几件事：

若是 A 和 B 能够合并到 master，刚能够将 A 和 B 合并到 master 中，而后用master的更新 C。

若是 A 和 B 不能合并到 master，能够简单地将 B 合并到 C 中，由于 B 已经包含了 A 的变动。

在极端的状况下，能够将 A、B 和 master 合并到 C 中。然而，为了不冲突，合并的顺序可能很重要。

39. 你使用的别名有哪些

我经常使用的一些 git 别名以下：

alias.unstage reset HEAD --
alias.append commit --amend --no-edit
alias.wip commit -m "WIP"
alias.logo log --oneline
alias.lola log --graph --oneline --decorate --all

40. 不为人知的 git 命令有哪些？

git bisect 是查找代码中存在的bug的救命工具。虽然只使用过几回，但它的精确度使人印象深入，节省了大量时间。

git archive 是用于打包一组更改的好工具。这有助于与第三方或 mico-deployment 共享工做。

git reflog 多是众所周知的，但值得一提，由于它提供了一种在出错时“撤消”命令的好方法。

41. 你能推荐一些关于Git的书籍吗

我建议至少阅读Pro Git的前三章。这些年来，每看到一遍，或多或少都有收获。

<Git 学习指南> 也不错。

---

代码部署后可能存在的BUG无法实时知道，过后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给你们推荐一个好用的BUG监控工具 Fundebug。

原文：https://dev.to/gonedark/42-gi...

---

交流

文章每周持续更新，能够微信搜索「 大迁世界 」第一时间阅读和催更（比博客早一到两篇哟），本文 GitHub https://github.com/qq449245884/xiaozhi 已经收录，整理了不少个人文档，欢迎Star和完善，你们面试能够参照考点复习，另外关注公众号，后台回复福利，便可看到福利，你懂的。