作者：Duomly已经收录在网站上，收录了更多类别的往期好评文章，也整理了很多我的文档和教程资料.欢迎来到星和完美。面试时可参考考点复习。我希望我们能在一起。1.你最喜欢的Git命令是什么？就个人而言，我喜欢gitadd-p。这增加了“补丁模式”的变化，这是一个内置的命令行程序。它遍历每个更改并要求确认它们将被执行。此命令迫使我们放慢速度并检查更改的文件。作为开发人员，我们有时会急于提交，而我自己也经常这样做。运行完gitadd.，发现调试的代码也提交了。2、为什么作为开发者更喜欢直接使用git命令，我们经常使用其他命令来做其他事情，使用git命令来做事情也不错。另外git命令也很短小，非常容易学，使用命令可以了解git的工作流程，间接提高了开发工作流程。3.如何使用stage命令stage是add的内置别名。4.如何在分支中保存修改并checkout到其他分支因此，可以使用gitstash来临时存储修改或者提交WIP，目的是有一个未修改的环境。就个人而言，我更喜欢使用WIP提交而不是存储，因为它们更容易引用和共享。WIP=WorkinProgress研发中的代码想存放，但是为了防止研发中的代码被合并，开发会创建一个WIP的分支。WIPMRWIPMR的意思是工作过程中的合并请求，这是我们在GitLabTechniques中为了避免MR还没准备好就被合并的合并请求。只需在MR标题的开头添加WIP:，除非您删除WIP:，否则它不会被合并。5.当你用gitstash发现一个class是多余的，你想删除它又担心以后需要查看它的代码，你想保存它又不想添加一个dirtycommit。这时候可以考虑gitstash。6.如何使用git命令对任何命令使用--help选项，例如gitstash--help。7.什么是“gitflow”？GitFlow为项目发布定义了一个分支模型，它为管理具有预定发布周期的大型项目提供了一个健壮的框架。是VincentDriessen提出的一个git操作流程标准，用来解决在分支过多的情况下如何有效快速的管理这些。分支。8.什么是GitHubFlow？GitHubflow，顾名思义，就是GitHub提倡的Workflow。（不要理解为只能在GitHub上使用的Workflow），基本上，GitHubFlow是master/feature分支工作流的品牌名称。GitHubFlow的核心优势在于其流程带来的自动化可能性，可以实现其他流程无法实现的检查流程，大大简化开发团队的手工劳动，从而真正发挥自身价值.大家都说简历里没项目可写，所以给大家找了一个项目，还给了一个【搭建教程】。9.你更喜欢哪种分支策略？大多数Git项目都是“Git流程”。这些项目中只有少数需要这种策略，通常是因为它是版本化的软件。master/feature分支策略更容易管理，尤其是刚开始的时候，如果需要的话切换到“gitflow”也很容易。10.gitopen命令有什么作用？这是一个单独的命令，可以用作npm包。11.当其他分支添加的文件在工作分支中仍然显示为未跟踪或修改时如何重置分支这通常是“工作索引”不干净时切换分支的结果。git中没有内置的方法来纠正这个问题。这通常可以通过确保提示具有“状态”指示器并在每次更改分支时运行gitstatus等命令来避免。这些习惯会让我们及早发现这些问题，以便我们可以在新分支上存储或提交这些更改。12.如何更名分行？gitbranch-mcurrent-branch-namenew-branch-name13.如何使用cherry-pickgitcherry-pick[参考]请记住这是一个重新应用命令，因此它会更改提交SHA。14.如果从分支恢复（例如HEAD~3），是否可以再次回到HEAD（比如恢复到上次更新）在这种情况下，通过运行gitreset--hardHEAD~1立即撤消恢复提交（即HEAD提交）。15.什么时候使用gitpull和gitfetch？gitpull将下载提交到当前分支。请记住，gitpull实际上是fetch和merge命令的组合。gitfetch将从远程获取最新的引用。一个很好的类比是播客播放器或电子邮件客户端。我们可能会检索最新的播客或电子邮件（获取），但实际上不会在本地下载播客或电子邮件附件（拉取）。16.为什么有时需要使用--force来强制提交更改rebase是一个可以重新提交的命令，它更改了SHA1哈希。如果是这样，本地提交历史将不再与其远程分支一致。发生这种情况时，推送将被拒绝。您应该考虑仅在被拒绝时才使用gitpush--force。这样做会用本地提交历史覆盖远程提交历史。所以你可以退一步想想为什么要使用--force。17.我可以使用分支合并多个分支，然后将该分支发送给master吗？当然，在大多数git工作流程下，一个分支通常会累积来自多个其他分支的更改，这些更改最终会合并到master分支中。18.我应该从一个非常老的分支做一个rebase吗？除非绝对必要。根据您的工作流程，可以将较旧的分支合并到主分支中。如果你需要一个最新的分支，我更喜欢rebase。与来自其他分支或合并的提交相比，它仅提供更清晰的更改历史记录。然而，尽管总是可行，但使用变基可能是一个痛苦的过程，因为每次提交都必须重新应用。这可能会导致多个冲突。如果是这样，我通常使用rebase--abort并使用merge一次性解决所有冲突。19.当使用rebase-isquash和fixup合并两个提交时，squash和fixup有什么区别。squash暂停rebase过程并允许我们调整提交消息。fixup自动使用来自第一次提交的消息。20.一般来说，当使用master对特性分支进行rebase时，每次提交都需要解决冲突？是的。由于每个提交的更改都在变基期间重新应用，因此必须在冲突出现时解决它们。意思是commit之前有commit冲突，如果解决不当，下面的很多commit也可能冲突。为了限制这种情况，我经常使用rebase-i来压缩提交历史，以便更容易使用。如果多次提交之间仍然存在冲突，则可以使用合并。大家都说简历里没项目可写，所以给大家找了一个项目，还给了一个【搭建教程】。21.与master合并之前是否需要更新我的分支？根据您的工作流程，您可以将旧分支合并到master分支中。如果您的工作流程仅使用“快进”合并，则有必要在合并之前更新您的分支。Gitfastforward提交多人协作开发。在使用Git时，您经常会看到包含以下术语的警告消息：快进，这是什么意思？简单的说，提交到远程中央仓库的代码必须是按照时间顺序的。比如A从中央仓库拿到代码后，修改了文件f。然后推送到中央仓库。B先于A拿到了中央仓库的代码，在A推送成功后也修改了f文件。这时B也运行push命令推送代码。您将收到类似于以下内容的消息：chenshu@sloop2:~/work/189/appengine$gitpushTossh://csfreebird@10.112.18.189:29418/appengine.git！[rejected]master->master(non-fast-forward)error:failedtopushsomerefsto'ssh://csfreebird@10.112.18.189:29418/appengine.git'为了防止你丢失历史记录，非快速-前向更新被拒绝在再次推送之前合并远程更改（例如“gitpull”）。有关详细信息，请参阅“gitpush--help”的“关于快进的注意事项”部分。提醒大家拒绝非快进更新，需要先从中央仓库pull到最新版本，合并后push.fastforward可以保证别人的代码不会被强行覆盖，保证协同开发多人。尽量不要使用非快进方式提交代码。22.需要使用像GitKraken这样的可视化工具吗？我更喜欢在命令模式下使用git，因为它让我可以完全控制管理更改以及使用命令来改进我的开发过程。当然，某些可视化操作（如管理分支和查看文件差异）在GUI中总是更好。我个人认为在合并期间在浏览器中查看这些就足够了。23.commit已经被推送时是否可以进行--amend？是的，gitcommit--amend不仅可以修改上次提交的内容，还可以修改提交说明。24、在做迭代内容的时候，完成一个小功能的时候，需要先拉一个pullrequest请求，或者完成迭代内容之后再拉一个pullrequest请求。我们通常的做法是在完成一个迭代的内容请求后进行拉取。但是，如果你在某项任务上花费了很长时间，那么合并先完成的功能可能会有好处。这样做可以防止分支上的依赖或过时，所以一次拉取还是一次拉取全部取决于你所做的更改的类型。25.合并分支到master之前需要先创建release分支吗？很大程度上取决于贵公司的部署过程。创建发布分支有利于将来自多个分支的工作分组在一起，并在将它们合并到主分支之前将它们作为一个整体进行测试。由于源分支保持独立且未合并，因此最终合并具有更大的灵活性。26.如何从master那里得到一些commit？比方说，我没有做最后一次提交，而是做了一个变基。假设master分支是我们的主要分支，我们不想有选择地从它的历史中提取提交，这会在以后引起冲突。我们想要合并或变基分支中的所有更改。要从master以外的分支中提取pick提交，您可以使用gitcherry-pick。27.如何在git终端中配置颜色默认情况下，git是黑白的。gitconfig--globalcolor.statusautogitconfig--globalcolor.diffautogitconfig--globalcolor.branchautogitconfig--globalcolor.interactiveauto配置好后就有颜色了。28.有没有更好的命令来代替gitpush-force？实际上，没有其他方法可以替代gitpush--force。即便如此，如果您正确地使用merge或rebase更新分支，则不需要使用gitpush--force。如果你已经运行了更改本地提交历史的命令，你应该只使用gitpush--force。大家都说简历里没项目可写，所以给大家找了一个项目，还给了一个【搭建教程】。29.当我在gitrebase中选择drop时——是否删除了与该提交相关的代码？是的。要恢复此代码，需要在reflog变基之前找到一个状态。30.如何自动跟踪远程分支通常，Git会在您签出或创建分支时自动设置分支跟踪。如果没有，您可以在下次更新时使用：gitpush-uremote-namebranch-name。或者它可以明确设置：gitbranch--set-upstream-to=remote-name/branch-name31。在rebase分支之前更新分支是好习惯吗？我认为是的，原因很简单gitrebase-i首先组织或压缩提交以在更新过程中提供更多上下文。32.有没有办法将一个提交拆分成更多的提交（与修复/压缩相反）？您可以在rebase-i期间使用exec命令尝试修改工作索引并拆分更改。您还可以使用gitreset撤消最近的提交，将它们的更改放入工作索引，然后将它们的更改分离到新的提交中。33.有没有办法查看固定提交？gitlog查看日志，找到对应的修改记录，但是这种查找只能看到文件，看不到文件内容。gitblamefilename查看这个文件的修改记录，默认显示整个文件，参数-L
