如何使用模板增强拉取请求
原文：https://www.gitkraken.com/blog/enhancing-pull-request-descriptions-templates
Syncfusion 更喜欢使用 Git 工作流来管理我们跨各种平台的所有复杂产品。自从在我们的开发阶段采用 Gitflow 模型以来，我们的日常工作已经被简化了。我假设这篇文章的读者已经熟悉了 Gitflow 的基础知识，并且知道拉请求在每个开发阶段的重要性。
作为开发人员，我们的责任不仅仅是修复问题或实现新的特性，而是将开发工作清楚地传达给评审人员。开发人员可以通过详细的文档或其他交流方式传达建议的代码更改及其目的。
这里是拉或合并请求的不可避免的描述发挥作用的地方，代码贡献者分享他们代码的详细注释。
GitKraken 团队在开发其工具时仔细考虑了团队协作:GitKraken Git 客户端和 Glo 板。在 GitKraken 中有很多机会为您的文件更改和拉取请求添加重要的上下文，git kraken 支持提交到 GitHub、GitLab 或 VSTS(包括具有传统 VSTS URL 的 Azure DevOps)上的远程回购的拉取请求模板。稍后会有更多相关信息…
描述在拉取请求中扮演什么角色？
为了更好的代码审查过程，强烈建议提供对拉请求的描述。描述清楚地回答:
- 评审者在评审提交的代码时可以期待什么？
- 在提交他们的代码供评审之前，开发人员考虑了哪些标准？
稍后，评审者可以在他们自己和开发人员之间发起一个公开的讨论，以便在那些变更被推进到存储库之前跟踪每一个代码变更。
描述清单
为了使“拉”请求尽可能清晰，它应该包括一个关于建议的代码更改的相关信息的适当清单(而不是一行摘要)，例如:
如何修复 bug 以及解决方案的描述。
- 对新功能的描述或总结。
- 涵盖的单元测试用例。
- 这段代码是否破坏了现有的功能。
- 任何测试细节。
- 是否在所有设备和浏览器中进行了测试。
- 是否在所有设备和浏览器中进行了测试。
如果每次您发出新的拉取请求时，这些清单都自动出现在描述字段中，这不是很好吗？好消息！Gitflow 模型通过模板选项提供了这种能力。
更好的是，GitKraken 让您在整个工作流程中轻松访问模板。在本文的后面，我们将回顾如何在 GitKraken 中使用 pull 请求模板。
更好的是，GitKraken 让您在整个工作流程中轻松访问模板。在本文的后面，我们将回顾如何在 GitKraken 中使用 pull 请求模板。
免费下载我们的 Git GUI 客户端，轻松访问拉请求模板。
免费下载我们的 Git GUI 客户端，轻松访问拉请求模板。
在下图中，您可以看到一个如何在拉取请求中查看这些描述的示例。
在下图中，您可以看到一个如何在拉取请求中查看这些描述的示例。
什么是拉取请求模板？
当您为项目存储库中已实现的功能或错误修复启动新的 pull 请求时，您可以允许 description 字段预先填充与您的团队相关的项目的清单，就像上一节中提供的清单一样。在拉请求表单中显示预先填充的描述字段的过程通常被称为拉请求或合并请求模板。
对于 description 字段中详细信息的自动预填充，您必须首先定义自己的一组模板，然后将它们添加到项目的根目录中。您还可以为 bug、特性、文档等分别创建多个模板…
描述模板通常被起草为 Markdown 文件，并且应该被添加到项目存储库的适当目录中。目录的命名，以及项目存储库中单个和多个模板的处理，根据您更喜欢使用的服务(GitHub 或 GitLab)而有所不同。出于本文的目的，我们将重点关注 GitHub。
注:参考降价文档了解如何根据提供的语法指南编写降价文件中的内容。
例如，您可以使用下面屏幕截图中显示的任务列表语法，引用减价文件中定义的清单。
相同的任务列表将显示在提交的合并请求页面中，如下所示。
相同的任务列表将显示在提交的合并请求页面中，如下所示。
如何在 GitHub 中创建单个拉请求模板
如果您的项目存储库在 GitHub 上，模板的名称和它在存储库中的位置非常重要。默认情况下，创建为 Markdown 文件的模板应该命名为PULL_REQUEST_TEMPLATE.md，并放在项目的根文件夹或.github目录中。
创建一个 Markdown 文件，将其命名为PULL_REQUEST_TEMPLATE.md，并将其放在项目的根文件夹中。
或者，创建一个目录，命名为.github，并将 Markdown 文件放在这个文件夹中。
注意:确保将 Markdown 文件放在前面提到的位置之一，并用相同的名称保存并合并。
现在，当您创建一个新的 pull 请求时，您将看到模板内容自动加载到 description 字段中，如下图所示。
现在，当您创建一个新的 pull 请求时，您将看到模板内容自动加载到 description 字段中，如下图所示。
在 GitKraken 中使用拉请求模板
正如我们之前简单提到的， GitKraken 支持 pull 请求模板提交到 GitHub、GitLab 或 VSTS 上的远程回购(包括带有传统 VSTS URL 的 Azure DevOps)。
当您在 GitKraken 中创建新的拉式请求时，将出现拉式请求模板下拉菜单，允许您选择您在其中一个存储库中创建的拉式请求。这使您可以使用预先起草的模板上指定的所有信息，轻松快速地填写拉动式请求。
https://www.youtube.com/embed/YUiz3uZ_2Gc?feature=oembed
视频
https://www.youtube.com/embed/YUiz3uZ_2Gc?feature=oembed
视频
如何在 GitHub 中创建多个拉请求模板
对不同类别的拉请求使用相同的描述模板是不明智的。例如，您可能需要发起一个 pull 请求来提交一个新实现的特性的代码变更、一个简单的 bug 修复、文档或者任何类型的配置工作。对于每个拉请求链接来说，最好根据提交的拉请求类别，在描述字段中加载和预填充不同的模板内容。
要使用不同的模板，您必须首先创建多个模板文件，并将它们作为单独的降价文件保存在存储库中，如以下步骤所述:
创建一个名为PULL_REQUEST_TEMPLATE的文件夹，并将其放在根目录或名为.github的目录中。
- 创建多个模板降价文件，并将它们全部放在文件夹
PULL_REQUEST_TEMPLATE中。 - 创建多个模板降价文件，并将它们全部放在文件夹
PULL_REQUEST_TEMPLATE中。
注意:在这个过程中创建的 Markdown 文件可以随意命名，但是第一步中提到的文件夹必须有名称PULL_REQUEST_TEMPLATE。
如果您在 GitHub 中有多个模板文件，您总是需要手动导航到您想要在 pull request 表单中预填充的特定 Markdown 文件的 URL。
例如，我正在创建一个 Markdown 文件，并将其命名为bug-template.md。我将它放在主存储库的PULL_REQUEST_TEMPLATE文件夹中。当我想将一些更改推入这个主存储库时，我将启动一个新的 pull 请求。为了用bug-template.md文件的内容预先填充我的拉取请求表单，我需要通过传递一个额外的模板参数导航到 URL:
https://github.com/Scheduler_Project/compare/master…Test_branch?expand=1&template=bug-template.md
这里，Scheduler-Project指的是我的主存储库的名称，我试图将来自Test_branch的代码变更合并到我的master分支中。在 URL 的末尾，有template=bug-template.md将bug-template.md文件的内容预填充到我的拉取请求表单中。
注:也可以参考 GitHub 帮助文档，里面解释了如何在 URL 中使用模板查询参数。
现在，在进行这些 URL 更改之后，您可以看到描述内容被加载到 pull request 表单中，如下所示。
您可以使用相关详细信息编辑之前的描述，并单击Create pull request按钮，这将打开您提交的拉取请求页面，如下所示。
您可以使用相关详细信息编辑之前的描述，并单击Create pull request按钮，这将打开您提交的拉取请求页面，如下所示。
在 GitLab 中创建合并请求模板
与 GitHub 存储库不同，GitLab 允许您在合并请求表单的用户界面中选择多个模板。
你可以在 GitLab 支持文档中看到更多相关信息。
结论
GitHub 和 GitLab 提供了一种更好的方法来为 pull 请求创建预定义的模板。两者都提供了模板选项，允许开发人员在评审过程开始时共享他们提出的代码变更的准确细节。提供更清晰的代码描述使得代码审查过程更容易，这反过来有助于实现更好的代码质量，并限制未被注意到的错误的风险。
一旦您花时间在 repo 中创建拉式请求模板，您和您的团队就可以在使用 GitKraken 时持续使用它们——节省您的时间，减少上下文切换，鼓励一致性，并提高生产率。
GitHub 和 GitLab 提供了一种更好的方法来为 pull 请求创建预定义的模板。两者都提供了模板选项，允许开发人员在评审过程开始时共享他们提出的代码变更的准确细节。提供更清晰的代码描述使得代码审查过程更容易，这反过来有助于实现更好的代码质量，并限制未被注意到的错误的风险。
一旦您花时间在 repo 中创建拉式请求模板，您和您的团队就可以在使用 GitKraken 时持续使用它们——节省您的时间，减少上下文切换，鼓励一致性，并提高生产率。
从开发人员到技术主管| GitKon 2022 | Eric Amodio，GitKraken
原文：https://www.gitkraken.com/gitkon/eric-amodio-interview-kerry-oshea-gorgone
https://www.youtube.com/embed/RoA2vJ9iu80?feature=oembed
视频
在这个特别的 GitKon 2022 会议中，Appfire 的高级编辑 Kerry O’Shea Gorgone 与 GitLens 的创建者兼 GitKraken 的 CTO Eric Amodio 坐在一起，听他讲述自己从一名独立开发者到一名开发开源产品的企业家，再到现在 GitKraken 团队的一名高管的历程。
Eric 是一名企业家、创新者、架构师和全栈工程师，GitLens 的创建者和 GitKraken 的 CTO，之前在微软和 CodeStream 的 VS 代码团队中担任工程领导职务。
埃里克早年的编码岁月
在成长过程中，Eric 喜欢乐高，实际上他把对软件的热情归功于他小时候做的修补工作。
埃里克的父亲是一名从事个人电脑工作的程序员，埃里克喜欢看他工作，甚至在他五岁的时候也是如此。他的父亲主要在 PC 上开发基于文本的终端，但他的家人也有一台“新 MAC”，埃里克喜欢玩它的图标和视觉功能。
随着软件工具越来越先进，Eric 开始接触微软的 Visual Basic，这改变了他的游戏规则。他觉得他第一次可以在脑子里构建东西，并实际创造出来。从那时起，Eric 迷上了从硬件到软件的转变。
凭激情成就事业
在大学里，Eric 决定从构建 CPU 转向构建软件，他看到了早期的成功，创建了几个小应用程序，并迅速流行起来。当时，还没有一个真正公开共享代码的地方，但 Eric 能够培养他对创建软件工具的热情。
当 Eric 第一次开始编码时，工具处于最前沿，但后来逐渐消失了。然后 VS 代码出来了，Eric 彻底爱上了；这重新激发了他对开发工具的热情。Eric 特别喜欢 VS 代码的开源特性和在工具上“入侵”的能力。
然后 Eric 有机会以微软员工的身份加入 VS 代码团队，并在那里工作了几年。
输入 VS 代码的 git lens
用 Eric 的话来说，GitLens 一开始是双重的:1)他想玩新推出的 VS 代码扩展模型，2)他想探索 TypeScript，这在当时是一项新技术。GitLens 提供了两者兼顾的机会。
CodeLens 在 Git 中存在并提供了关于代码更改作者的信息，所以 Eric 认为他可以在 VS 代码中复制这一点，他是对的。他最终希望在不离开 VS 代码的情况下，让他和他的团队更好地理解 Git 内部的情况。
Eric 热衷于构建工具，热衷于让自己的生活变得更轻松的事情，他致力于让 GitLens 成为最好的工具，并继续在它的成功基础上发展。
Eric 说，当 GitLens 在多个微软主题演讲中被提及时，当他开始在 Twitter 上看到专用于该工具的 memes 时，他就知道 GitLens“成功了”，开发人员幽默地发布关于 Git 责备功能的帖子，提醒他们注意自己的错误。
【GitLens 如何取得成功
Eric 将 GitLens 的流行归功于几个因素。该工具在该领域处于早期阶段，但不仅如此，一旦用户安装了 GitLens，他们就会立即获得“被动价值”，这意味着他们不必做任何事情就可以获得有价值的信息，帮助他们理解他们正在查看的代码。从那里，用户可以轻松地使用越来越多的产品。
开发人员空间和 VS 代码中的一个趋势是让这些非常小的工具做一件事情，并且你必须将多个工具组合在一起以创建一个内聚的体验。Eric 想为 GitLens 走一条相反的路，这意味着通过引入付费的 GitLens+功能让这个工具更加健壮。但是 Eric 不想影响任何不需要使用这些协作工具的用户的性能，所以将这些功能设为可选。
【GitLens 的下一步是什么
Eric 有一个构建工具来更好地处理“Git 部分”的愿景；让 Git 变得更容易访问，并继续其“为 Git 增压”的使命。该工具还可以做更多的事情来增强使用 Git 的能力，同时还可以简化开发人员的工作流程。
不要错过新的 GitLens+特性，它们在 VS 代码中实现了更好的可视性和团队协作！
如何在敏捷开发中使用快速反馈循环
原文：https://www.gitkraken.com/blog/feedback-loops-agile-development
文章更新于 2020 年 9 月
我最喜欢的格言之一是“快速移动，打破东西”。不幸的是，当谈到软件时，我们倾向于打破东西，而不是移动得很快。敏捷开发的目标是以更高的速度发布代码。关键是足够有效地管理过程，同时不破坏东西——或者至少减少东西。
在这篇文章中，我将提供一些关于如何实现 DevOps 和使用 Scrum 框架快速反馈循环来提高速度和质量的技巧。
AXO soft 的 Scrum 开发时间表
什么是反馈回路？
创建好的软件最关键的是沟通。反馈循环是用于验证和获得关于软件开发过程的反馈的机制。目标是获得能够立即反馈到流程中的正反馈和负反馈。尽可能快地这样做可以加速和改善整个开发过程。
反馈回路的类型
反馈循环不仅仅是验证你写的代码是否符合用户的需求。尽管这很重要。知道你的代码是否有效，是否充满了错误也是很重要的。反馈循环是日常最佳实践、自动化和工具的混合体。你最不希望的事情就是让你的用户对你所做的事情真正感到兴奋，然后当事情闹得满城风雨时，他们会发疯。
每日混战
能够快速说出你的进展并向你的整个团队提出简单的问题是持续分享反馈的一个很好的方式。简单地提及你正在做的事情可能会激发队友提及你可能想要避免的潜在问题。
召集您的团队进行一致的面对面会议，即使你们都远程工作，也可以提供有价值的集体项目可见性。每日例会(有时被称为每日站立会议)是一个向你的团队寻求反馈或帮助的好地方，这样你就可以让你的项目继续前进。
Daily Scrum
会见利益相关者并获得用户反馈
没有什么比用户反馈更重要的了。你最不想做的事情就是花很多时间走错方向。同样，让任何有权改变项目基本方面的利益相关者参与进来，对你也有好处。
避免执行瓶颈，同时通过 GitKraken Timelines 等工具为正在进行的项目提供透明度，使项目时间表和里程碑的规划和沟通变得轻松愉快。
与利益相关者和用户会面是至关重要的，而且不一定要花很多时间。尽量避免持续的有组织的会议，这可能是一个很大的时间吸。相反，利用 Slack 这样的交流工具来保持联系。鼓励用户提交特性请求和 bug 报告的社区 Slack 频道可以很好地收集用户反馈。
在吉克拉肯湖社区的讨论
没有什么比用户反馈更重要的了。你最不想做的事情就是花很多时间走错方向。同样，让任何有权改变项目基本方面的利益相关者参与进来，对你也有好处。
避免执行瓶颈，同时通过 GitKraken Timelines 等工具为正在进行的项目提供透明度，使项目时间表和里程碑的规划和沟通变得轻松愉快。
考虑利用项目管理工具，比如与 Slack 集成的 GitKraken Boards，这样你的团队就可以跟踪日常对话中出现的任务。
代码分析和跟踪
你的代码刚才做了什么？表现如何？开发人员现在可以使用一些神奇的工具来帮助实时回答这些问题。当您在工作站上编写和测试代码时，您可以获得关于代码执行情况和正在做什么的即时反馈。这些应用性能管理 (APM)工具可以向您显示 SQL 查询、HTTP web 服务调用、错误、日志消息等等。查看免费 APM 工具，如 Stackify Prefix、DevTrace、MiniProfiler 等。它们因您的编程语言而异。
此外，像 Grafana 这样的监控工具能够本地支持来自多个来源的数十个数据库。生成热图、直方图、地理图、定制仪表板等。
拉式请求和代码审查
拉请求可以帮助确保你的代码在准备好之前不会被合并和部署。当很多人不停地签入代码时，很难知道您是否准备好进行部署。拉请求也提供了一个很好的机会来做一些快速的代码审查。在发布代码之前，来自团队的反馈对于发现潜在问题至关重要。
你的代码刚才做了什么？表现如何？开发人员现在可以使用一些神奇的工具来帮助实时回答这些问题。当您在工作站上编写和测试代码时，您可以获得关于代码执行情况和正在做什么的即时反馈。这些应用性能管理 (APM)工具可以向您显示 SQL 查询、HTTP web 服务调用、错误、日志消息等等。查看免费 APM 工具，如 Stackify Prefix、DevTrace、MiniProfiler 等。它们因您的编程语言而异。
在这个中级 Git 教程视频中，了解更多关于 Git 中的 pull 请求以及如何使用 PRs 提升您的工作流的信息。
拉式请求和代码审查
“拉”请求实质上是请求某人在您的更改最终完成之前对其进行审核。
在这个中级 Git 教程视频中，了解更多关于 Git 中的 pull 请求以及如何使用 PRs 提升您的工作流的信息。
作为 Git 客户端，GitKraken 更进一步，支持来自 GitHub、GitLab 和 Azure DevOps 存储库的 pull 请求模板。了解如何通过模板增强拉取请求。
立即开始使用 GitKraken Git 客户端处理拉请求。
持续集成和部署
您只能以部署代码的速度发布代码。自动化构建和部署的方式至关重要。它消除了人为错误，加快了流程。在您完成一个部署并需要快速修复一个 bug 之后，能够检查它并进行快速的新部署是非常重要的。利用持续集成来每天或持续运行单元测试也是一个非常有价值的反馈循环。
通常，持续集成(CI)包括每天多次将代码合并到共享的 repo 中，然后进行构建和自动化测试。devo PS 领域流行的 CI/CD 工具包括 Jenkins 和 Travis CI。
立即开始使用 GitKraken Git 客户端处理拉请求。
在生产前环境中验证性能
希望您的 QA 团队在测试您的应用程序方面做得很好。在 QA 过程中，这是寻找应用程序错误和审查整体性能的好时机。应用监控解决方案可以帮助您做到这一点。如果你的应用在预生产环境中没有任何流量，合成测试和负载测试会有所帮助。
在一个完美的世界里，你希望在软件进入生产之前找到它们。谢天谢地，市场上已经出现了测试工具，这使得 QA 团队的工作变得更加容易。
单元测试
测试框架应该用来为跨团队创建和设计用例提供高层次的指导方针。一些面向 DevOps 开发人员的测试工具包括 JUnit、Jest、Selenium 和 PhPUnit。
单元测试、集成测试、自动化 web 测试等等，提供了一个快速的反馈循环。我开发的一个应用程序有超过 100 个复杂的集成测试。每当我对代码进行任何修改时，我都会在我的工作站上重新运行所有的测试，以确保我没有破坏任何东西。这些测试对我来说是一个关键的快速反馈环。没有它们，我无法对应用程序进行更改！
希望您的 QA 团队在测试您的应用程序方面做得很好。在 QA 过程中，这是寻找应用程序错误和审查整体性能的好时机。应用监控解决方案可以帮助您做到这一点。如果你的应用在预生产环境中没有任何流量，合成测试和负载测试会有所帮助。
监控生产绩效
你刚刚把你的新版本推向生产。恭喜你。！现在怎么办？这是一个很好的时机来监控你的代码中出现的新错误。很可能你会有几个。无论你在产品化之前对你的软件做了多少测试，你总会在产品中发现一些奇怪的问题。客户数据、流量和主机的差异都很难事先测试。
应用程序监控对于尽快发现潜在问题至关重要。您应该监控整体性能，以确保您的应用程序不会运行得更慢，使用更多的 CPU，等等。这些都是潜在的问题，如果您使用应用程序监控最佳实践，您可以快速检测并修复这些问题。
Azure 是微软的一个工具，它让你的应用程序、基础设施和网络变得非常透明。为您的开发运维战略获取更多监控工具。
微软 Azure Monitor
跟踪产品使用情况
你知道有多少客户在使用你的新功能吗？了解你的产品是如何被使用的是一个重要的反馈环。有几种方法可以做到这一点。
你可以使用简单的 Google Analytics，但是如果你的应用程序使用 REST 风格的 URL，它就不能很好的工作。如果你正在使用 APM 解决方案，如 Retrace、New Relic、App Insights 等。，它们可能能够提供一些关于代码的某些部分被访问的频率的见解。如果你想要更高级的功能，试试完整版。看起来很神奇。
摘要
每个开发团队和软件项目都是不同的。你的目标应该是找出在保持高质量的情况下你能走多快，然后就走那么快。如果走得太快降低了质量，那么你就有一个好主意，在哪里释放加速器。希望这些提示和快速反馈会有所帮助！
微软 Azure Monitor
跟踪产品使用情况
你知道有多少客户在使用你的新功能吗？了解你的产品是如何被使用的是一个重要的反馈环。有几种方法可以做到这一点。
你可以使用简单的 Google Analytics，但是如果你的应用程序使用 REST 风格的 URL，它就不能很好的工作。如果你正在使用 APM 解决方案，如 Retrace、New Relic、App Insights 等。，它们可能能够提供一些关于代码的某些部分被访问的频率的见解。如果你想要更高级的功能，试试完整版。看起来很神奇。
摘要
每个开发团队和软件项目都是不同的。你的目标应该是找出在保持高质量的情况下你能走多快，然后就走那么快。如果走得太快降低了质量，那么你就有一个好主意，在哪里释放加速器。希望这些提示和快速反馈会有所帮助！
Summary
Every development team and software project is different. Your goal should be to figure out how fast you can go while maintaining high quality, and then go that fast. If going any faster reduces quality, then you have a good idea of where to let off the accelerator. Hopefully, some of these tips and fast feedback loops will help!
流程工程| GitKon 2022 | Steve Pereria，可见价值流咨询
原文：https://www.gitkraken.com/gitkon/flow-engineering-steve-pereira-value-stream
https://www.youtube.com/embed/tw3whUFQuXc?feature=oembed
视频
当我们在软件开发中谈论流程工程时，它指的是集体流程。在整个组织中流动的想法意味着涉及所有的活动和所有需要发生的事情，从一个想法的开始，从客户的要求到生产，并看到客户使用你的努力成果。
除了组织流程，开发人员考虑个人流程也很重要。流畅的状态是挑战和技巧的完美结合；在那里你会觉得自己“进入状态”
集合流水工程
话虽如此，但重要的是要认识到，如果没有集体流动，就很难达到这种状态，如果你在孤岛中工作，这可能很难实现，这是团队在这种新的远程工作环境中越来越多地面临的问题。
因此，开发人员在不同时区、不同部门、不同部门，甚至可能是不同公司的团队之间进行更多的协作。这使得集体流工程在应对现代协作挑战中变得更加重要。
提升速度、质量、&开发人员的幸福感
如今，大型组织都有着雄心勃勃的目标:转变业务、进军新市场、为客户推出新产品和新体验。虽然这些都是有价值的努力，但它们经常导致需要完成的任务大量积压。
那么，我们如何才能让这些计划真正开花结果，实现这些成果呢？我们如何才能足够快地取得更好的结果？
重要的是要以正确的方式来避免开发人员精疲力竭，并实现高绩效的可持续结果。你不想以牺牲质量为代价去追求速度。协作流程通常会因需要完成的工作缺乏明确性而受阻。
开发人员和团队也不清楚他们如何达到下一个水平来提高性能和成果。这在协作环境中很难做到，因为多个人意味着多种观点和经历。这会导致每个人都朝着不同的方向前进。为了实现集体流动，每个人都需要朝着同一个方向划船。
那么，你如何让每个人都清楚团队的前进方向，以及你将如何到达那里？第一步是将所有利益相关者聚集在一起，达成共识。一个好的策略是从一个目标结果开始，然后从那里制定你的小目标和任务。
价值流图
价值流图技术的价值完全在于集体流。这个策略指的是从开始到结束，围绕你的产品或服务如何为顾客提供价值，展开所有的活动；你的工作流程是什么样的；您目前的运营顺序是什么？
价值流图的一个极其重要的方面是测量。如果地图不代表现实或呈现任何有意义或可操作的东西，没有测量的地图可能是无用的。另一方面，价值流图背后有数据和度量。
要获得这些数据，您需要询问您的团队完成任务需要多长时间，从请求被记录到系统中到被实现需要多长时间。
另一个有价值的数据点是延迟时间。人们会因为无效的任务管理而在活动之间等待多久？还是因为步骤不清晰？您可能会发现您的团队没有使用正确的工具来实现正确的移交。
价值流图在一个地方给你所有你应该注意的东西。
如果您希望提高团队的速度、质量和开发人员的幸福感，那么看看 GitKraken 套件 Git tools 就知道了，该套件是为协作和开发体验而设计的。
桌面版 GitKraken Client 使 Git 更加直观和易于访问，并为开发人员提供了使用 GUI 或终端完成操作的选项。
GitLens for VS Code 通过可视化 VS 代码中的代码作者和责备来解锁知识。
吉拉 Git 集成将 Git 数据引入吉拉，以提高团队中每个人的透明度和责任感。
使用 GitLens 获取 VS 代码|责备、代码透镜等 Git 信息
这篇文章是由 通过 同步带给你的。
GitLens 是一个为 Visual Studio 代码构建的流行扩展，帮助开发人员提取隐藏在 Git 代码库中的强大洞察力。这个 VS 代码扩展通过提供快速浏览、比较和跟踪每一行代码的工具，使开发变得毫不费力。它还有助于解决大规模项目中本机 Git 特性的缺点和侵扰性。
本文将概述单独使用 Git 时很难发现的洞察，以及 GitLens 如何在您的 IDE 中神奇地发现它们。
GitLens+解锁了强大的团队功能，如可视化文件历史，它向您显示何时、由谁以及它们的重要性进行了更改。
Sign up for GitLens+ for free!
在本文中，我们将回顾 GitLens 和 GitLens+中提供的一些特性，这些特性帮助用户在工作流程中的多个点快速获取 Git 信息。
Git 的“黑暗”面
尽管 Git 有许多开发人员友好的原生特性，比如查看当前的变更日志和遍历提交，但是毫不费力的变更跟踪并不在其中。因为使用 Git 和 GitLens 这样的工具缺乏做出明智决策所需的环境，开发人员经常被迫切换到 Git GUI 或其他工具，而不是直接在他们已经工作的 IDE 中比较和跟踪变化。
虽然这可能不是一个噩梦，但是缺乏对项目的适当的可见性会给开发人员带来一些不适。事实上，让我们看看在没有 GitLens 的情况下使用 Git 和 VS 代码时缺少的一些重要部分。
Git 中的修订导航
Git 没有提供一种简单的方法来浏览 ide 中的多个版本。开发人员必须切换到在托管服务或 web 浏览器上查看他们的 Git 存储库，并手动浏览各种提交，以便跟踪更改。
这种转换中断了开发工作流，因为它要求开发人员切换应用程序。此外，即使查看了特定文件上的提交，开发人员也必须检查每个提交，以检查提交影响的行。
Git 没有提供一种简单的方法来浏览 ide 中的多个版本。开发人员必须切换到在托管服务或 web 浏览器上查看他们的 Git 存储库，并手动浏览各种提交，以便跟踪更改。
这种转换中断了开发工作流，因为它要求开发人员切换应用程序。此外，即使查看了特定文件上的提交，开发人员也必须检查每个提交，以检查提交影响的行。
Git 中的逐行差异跟踪
当使用 Git 和没有 GitLens 的 IDE 时，开发人员不得不走很长的路来跟踪多个文件修订中的变化。通过多次修订检查一行代码的更改的唯一方法是检查每次提交并手动比较差异。
如果没有像 GitLens 这样的工具，这个过程会非常耗时，在开发人员可以解决关键问题的时候会分散他们的注意力。
跟踪最近的 Git 文件更改
当生产环境中出现关键问题时，快速找到问题的根源至关重要。如果您认为它是由于最近的更改而发生的，那么识别更改和作者是第一步。
尽管 Git 提供了作者及其更改的视图，但它不允许开发人员快速浏览多个开发人员所做的数千个更改。这很困难，并且需要花费大量的精力，尤其是当所讨论的更改来自多次提交时。
跟踪最近的 Git 文件更改
GitLens 改进了 VS 代码和 Git 的使用
GitLens 将 Git 存储库增加的洞察力直接引入到最流行的 IDE VS 代码中。这非常有益的原因有很多，包括通过防止需要在不同任务的多个应用程序之间切换来保持平稳完整的工作流。
下面的 GitLens 特性通过让使用 Git 和 VS 代码的开发工作流更加高效，提高了开发人员的工作效率。
GitLens 责备
GitLens 责备在每一行的末尾插入一个清晰的注释，显示最后一次提交及其作者:
下面的 GitLens 特性通过让使用 Git 和 VS 代码的开发工作流更加高效，提高了开发人员的工作效率。
通过将鼠标悬停在注释上，您可以很容易地看到关于更改的更多细节。
GitLens 责备
GitLens 责备在每一行的末尾插入一个清晰的注释，显示最后一次提交及其作者:
作为一个特性，GitLens 责备为开发人员提供了更多的可见性，并允许他们直接从他们的 IDE 中查看信息。他们只需将光标移动到某一行，而无需输入任何 Git 命令。
git 无代码
Git CodeLens 在识别文件或代码块的最新变更时非常有用。这对于确定哪个修改破坏了应用程序至关重要。CodeLens 在文件或特定代码块的顶部显示最近的更改和作者。
在 GitLens 中，CodeLens 还允许开发人员查看关于提交的更多信息，并让他们通过点击文件或代码块顶部的作者姓名来跟踪每一行。
CodeLens 在代码的当前版本旁边显示每个 Git commit ，这使得跟踪更改变得容易。
git 无代码
Git CodeLens 在识别文件或代码块的最新变更时非常有用。这对于确定哪个修改破坏了应用程序至关重要。CodeLens 在文件或特定代码块的顶部显示最近的更改和作者。
使用 GitLens 中的 CodeLens 跟踪每次提交的更改再简单不过了。将鼠标悬停在提交上，更改会神奇地出现在代码中！
在 GitLens 中，CodeLens 还允许开发人员查看关于提交的更多信息，并让他们通过点击文件或代码块顶部的作者姓名来跟踪每一行。
当您单击单个提交时，CodeLens 更进一步。它显示了一次提交中所做的所有更改，并为它们着色以便于查看。
Git 装订线更改
Git gutter changes 特性添加了一个颜色编码的热图，用于标识特定文件的最新更改。此外，它提供了对文件所做更改的视图，允许开发人员缩小最近编辑的代码行。
使用 GitLens 中的 CodeLens 跟踪每次提交的更改再简单不过了。将鼠标悬停在提交上，更改会神奇地出现在代码中！
GitLens 的这个特性还允许开发人员根据自己的喜好定制注释。
Git Gutter 热图
Git gutter 热图类似于 Git gutter changes 特性，但是它跟踪最近的更改，并在一行代码变冷时分配不同的颜色。默认情况下，90 天后的线路被认为是冷的，但是这可以在设置中自定义。
更好的版本导航
GitLens 提供了强大的能力，通过并排比较修订版和文件的当前版本，可以在一个 Git 存储库中的所有可用修订版之间跳转。
单独使用您的 IDE，这将需要相当大的努力。然而，使用 GitLens，只需几秒钟。
GitLens+功能
虽然 GitLens 提供的大多数功能都是完全免费的，不需要帐户，但也有一个免费的基于帐户的版本，名为 GitLens+ ，它包括工作树和可视文件历史等附加功能，以进一步提高生产力和改善团队协作。GitLens+对于公共存储库是完全免费的。用户还可以升级到 GitLens+ Pro ，以很低的价格访问工作树和私人回购上的可视文件历史等功能。
GitLens 的这个特性还允许开发人员根据自己的喜好定制注释。
GitLens+具有强大的功能，如可视化文件历史，让您快速浏览项目变更的极有价值的信息。
可视文件历史
GitLens+中的可视化文件历史视图允许开发人员可视化项目中单个文件的演变，包括每个作者的更改和贡献。
可视化表示使开发人员可以很容易地通过彩色编码的插图快速识别所有更改。变化的幅度由图中圆圈的大小表示。
更好的版本导航
GitLens 提供了强大的能力，通过并排比较修订版和文件的当前版本，可以在一个 Git 存储库中的所有可用修订版之间跳转。
VS 代码+ Git 用 GitLens 更好
我们已经讨论了在 IDE 中使用 Git 与在同一个工作流中使用 vs 代码、Git 和 GitLens 在开发人员体验上的区别。本文中重点介绍的 GitLens 特性将通过将繁琐的步骤简化为几个毫不费力的鼠标点击来提高开发人员的工作效率，所有这些都不需要离开您的 IDE。
这篇博客是由 Syncfusion 的一位作者写的。 Syncfusion 拥有超过 1700 个组件和框架，用于 WinForms 、 WPF 、 WinUI 、。NET MAUI(预览版)、ASP.NET(Web Forms、 MVC 、 Core )、 UWP 、 Xamarin 、 Flutter 、 JavaScript 、 Angular 、 Blazor 、 Vue 和考虑使用它们来加速您的应用程序开发。
虽然 GitLens 提供的大多数功能都是完全免费的，不需要帐户，但也有一个免费的基于帐户的版本，名为 GitLens+ ，它包括工作树和可视文件历史等附加功能，以进一步提高生产力和改善团队协作。GitLens+对于公共存储库是完全免费的。用户还可以升级到 GitLens+ Pro ，以很低的价格访问工作树和私人回购上的可视文件历史等功能。
如果您正在使用 VS Code + Git，您可以通过有用的见解增强您的工作流程并做出更好的决策——Git lens+完全免费。
GitLens+具有强大的功能，如可视化文件历史，让您快速浏览项目变更的极有价值的信息。
Sign up for GitLens+ for free!
可视文件历史
GitLens+中的可视化文件历史视图允许开发人员可视化项目中单个文件的演变，包括每个作者的更改和贡献。
可视化表示使开发人员可以很容易地通过彩色编码的插图快速识别所有更改。变化的幅度由图中圆圈的大小表示。
The visual representation makes it easy for developers to identify all changes quickly with color-coded illustrations. The magnitude of the change is represented by the size of the circle in the graph.
VS 代码+ Git 用 GitLens 更好
我们已经讨论了在 IDE 中使用 Git 与在同一个工作流中使用 vs 代码、Git 和 GitLens 在开发人员体验上的区别。本文中重点介绍的 GitLens 特性将通过将繁琐的步骤简化为几个毫不费力的鼠标点击来提高开发人员的工作效率，所有这些都不需要离开您的 IDE。
这篇博客是由 Syncfusion 的一位作者写的。 Syncfusion 拥有超过 1700 个组件和框架，用于 WinForms 、 WPF 、 WinUI 、。NET MAUI(预览版)、ASP.NET(Web Forms、 MVC 、 Core )、 UWP 、 Xamarin 、 Flutter 、 JavaScript 、 Angular 、 Blazor 、 Vue 和考虑使用它们来加速您的应用程序开发。
This blog was written by an author from Syncfusion. Syncfusion has over 1,700 components and frameworks for WinForms, WPF, WinUI, .NET MAUI (Preview), ASP.NET (Web Forms, MVC, Core), UWP, Xamarin, Flutter, JavaScript, Angular, Blazor, Vue, and React. Considering using them to speed up your application development.
如果您正在使用 VS Code + Git，您可以通过有用的见解增强您的工作流程并做出更好的决策——Git lens+完全免费。
If you’re using VS Code + Git, you can enhance your workflow and make better decisions with helpful insights – completely free with GitLens+.
Sign up for GitLens+ for free!
了解如何使用 Git 添加命令|全部、交互式、撤消
Git 允许您随着时间的推移拍摄存储库的快照。这些快照中的每一个都被称为 Git 提交。但是 Git 怎么知道我们要提交什么信息呢？
这就是 Git add 的用武之地。Git add 是一个命令，它允许您转移单个文件，或者一次转移项目目录中的所有文件，为转移它们做准备。Git add 是 Git 中最重要和最基本的命令之一，有很多方法可以使用它。本文将介绍 Git add 如何工作，以及使用该命令的一些可选方法。
“@GitKraken 无疑是我今年发现的最好的工具之一，它显著提高了我作为软件开发人员和作者的效率。”–@ hflickster
添加 Git 索引
Git add 是一种用于暂存即将提交的文件的机制。您可能会问:“Git 将文件添加到什么地方？”这是一个好问题。在每个 Git repo 内部，都有一个名为.git的文件。这个文件是在用 Git init 创建项目时创建的。Git 使用这个文件来跟踪存储库中的所有更改和工作。其中一个文件。git 文件夹包含的内容称为“索引”
Git add 是一种用于暂存即将提交的文件的机制。您可能会问:“Git 将文件添加到什么地方？”这是一个好问题。在每个 Git repo 内部，都有一个名为.git的文件。这个文件是在用 Git init 创建项目时创建的。Git 使用这个文件来跟踪存储库中的所有更改和工作。其中一个文件。git 文件夹包含的内容称为“索引”
当运行 Git add 时，Git 将工作目录中修改和保存的文件压缩成二进制大对象，也称为 blobs，并将它们添加到索引文件中。这里的索引文件充当单个 blobs 的临时区域。您可以随意修改索引，直到您准备好通过执行 Git commit 来永久记录项目的状态。
当运行 Git add 时，Git 将工作目录中修改和保存的文件压缩成二进制大对象，也称为 blobs，并将它们添加到索引文件中。这里的索引文件充当单个 blobs 的临时区域。您可以随意修改索引，直到您准备好通过执行 Git commit 来永久记录项目的状态。
您实际上可以打开索引，但您将无法读取存储在那里的绝大多数内容，因为它是以压缩形式存在的，只有文件名仍然清晰可辨。
去添加全部
当向索引中添加文件以准备提交这些更改时，您可以选择一次存放一个文件，或者您可以告诉 Git 存放工作目录中已经修改并保存的所有文件。实际上有几种不同的方法可以一次添加所有文件。
提交所有文件，可以使用选项--all，或者简称为-A。该命令将被结构化:
git add -A
或者，您可以使用特殊字符.(称为“点”)来指定当前目录以及所有子目录要使用此方法暂存所有文件，请使用以下命令:
git add .
注意:虽然一次将所有文件添加到索引中很方便，但是要小心不要过度使用这两种方法。如果不小心，您可能会意外添加、提交和 Git push 未准备好或从未打算提交给回购的东西。
或者，您可以使用特殊字符.(称为“点”)来指定当前目录以及所有子目录要使用此方法暂存所有文件，请使用以下命令:
git add .
Git 添加互动
在命令行上学习 Git 可能很困难，所以 Git 的创建者增加了一个交互模式，你可以用-i或--interactive调用它。
通过在交互模式下运行 Git add，Git 将向您显示一个可能选项的菜单，并让您对每个文件做出决定。这是一种非常安全的工作方式，它可以让你在任何给定的时间内对指数的进出进行精细的控制。要调用交互模式，请使用以下命令:
git add -i
Git 添加交互模式的选项包括:
状态–显示有变化的路径
更新–将工作树状态添加到阶段化的变更集中
恢复–将暂存的变更集恢复为原始版本
添加未跟踪文件–将未跟踪文件的内容添加到暂存的变更集中
-
补丁——挑选大块并有选择地更新
-
差异–查看标题和索引之间的差异
-
退出–退出 Git 添加交互模式
-
帮助–将帮助菜单打印到屏幕上
-
放弃去添加
-
您可以完全控制索引文件中存放的内容。这意味着您也可以在将内容添加到暂存索引后删除它们，从而有效地撤销 Git 添加。从索引中删除文件有几种方法:一次删除一个文件，或者一次删除索引中的所有文件。
要从索引中删除单个暂存文件，使用命令:
git rm --cached <filename> -
将替换为要从暂存中删除的文件的名称。
要同时删除索引中暂存的所有文件，使用
git reset HEAD -- <directory-name>命令 -
将替换为您的存储库的目录名。
如果您想要从您正在工作的目录中移除暂存的所有文件，您可以使用快捷键.来引用当前目录。
git reset HEAD – .
您可以完全控制索引文件中存放的内容。这意味着您也可以在将内容添加到暂存索引后删除它们，从而有效地撤销 Git 添加。从索引中删除文件有几种方法:一次删除一个文件，或者一次删除索引中的所有文件。
要从索引中删除单个暂存文件，使用命令:
git rm --cached <filename>
GitKraken Client 可以让你很容易地看到你的存储库中发生了什么，并随时掌握最新的变化，无论你在索引中添加了多少文件！
将替换为您的存储库的目录名。
如何在命令行中添加 Git
在命令行中，您可以 Git 添加您修改和保存的文件，一次一个或者一次全部添加。
要对单个文件执行 Git 添加，使用命令:
git add <filename>
用您想要添加的文件名替换。
在命令行中，您可以 Git 添加您修改和保存的文件，一次一个或者一次全部添加。
当您在 CLI 中工作时，运行 Git status 来确保操作按预期执行总是一个好主意。
Psst:当你在 GitKraken 客户端中使用终端时，你不需要运行额外的命令来确保动作按预期执行。GitKraken 图形将同时自动更新，如上所示，因此您可以验证执行了哪些操作以及项目历史是如何更新的。
您也可以一次添加多个文件，只需在 Git add 后输入每个文件名。
git add <filename1> <filename2> <filenameN>
用您要添加的文件名替换上面编号为<的文件名>条目。
当您在 CLI 中工作时，运行 Git status 来确保操作按预期执行总是一个好主意。
您也可以使用A选项将所有修改过的文件一次性添加到工作目录中:
git add -A
如何使用 GitKraken 客户端进行 Git 添加
使用 GitKraken 客户端，将文件添加到索引非常容易。GitKraken 客户端会一直显示你修改文件的状态，不需要运行任何命令或者点击任何选项。该状态在位于应用程序中央 UI 右侧的提交面板中可用。
您也可以使用A选项将所有修改过的文件一次性添加到工作目录中:
要将单个文件添加到临时区域(也称为索引),请使用将鼠标悬停在提交面板中的文件名上时会出现的Stage File按钮。
您甚至可以通过将鼠标悬停在提交面板的Stages Files部分中的文件名上来取消转移文件。
如何使用 GitKraken 客户端进行 Git 添加
使用 GitKraken 客户端，将文件添加到索引非常容易。GitKraken 客户端会一直显示你修改文件的状态，不需要运行任何命令或者点击任何选项。该状态在位于应用程序中央 UI 右侧的提交面板中可用。
GitKraken 客户端还允许您使用提交面板中的Stage all changes按钮一次添加所有修改的文件。
要将单个文件添加到临时区域(也称为索引),请使用将鼠标悬停在提交面板中的文件名上时会出现的Stage File按钮。
将 GitKraken 客户端添加到您的工作流程中
GitKraken Client 使得在任何给定的时间查看项目的状态变得非常容易，节省了您试图记住您需要运行什么命令来查看您修改的文件的时间和精力。
GitKraken Client 可以通过更好地可视化提交历史来帮助您控制存储库，无论您处于提交周期的哪个阶段。今天就下载并开始免费使用 GitKraken 客户端，以确保您充分利用 Git。
GitKraken 客户端还允许您通过提交面板中的Stage all changes按钮一次性添加所有修改的文件。
将 GitKraken 客户端添加到您的工作流程中
GitKraken Client 使得在任何给定的时间查看项目的状态变得非常容易，节省了您试图记住您需要运行什么命令来查看您修改的文件的时间和精力。
GitKraken 客户端可以通过更好地可视化提交历史来帮助您控制您的存储库，无论您处于提交周期的哪个阶段。下载并开始免费使用 GitKraken 客户端,确保您充分利用 Git。
你为什么对这件事这么迟钝？| Git 最佳实践
你为什么对这件事这么迟钝？
https://www.youtube.com/embed/AN-iaHcXgYI?feature=oembed
视频
Git 是当今世界上最流行的源代码控制管理系统。Git 可以确保您的代码得到备份和版本控制，还可以让其他开发人员访问您的工作。如果使用得当，Git 不仅仅是一种存储或组织代码的方式。Git 可以帮助简化复杂的过程，比如发布管理、特性开发，以及与多人同时工作。
在 2021 GitKon Git Conference 的会议中，Joe Glombek 分享了他最喜欢的 Git 最佳实践。剧透:对如何使用 Git 非常挑剔是可以的！这其实是一件好事。
无论您喜欢在 GUI 或 CLI 中工作，GitKraken Client 都可以在您已经工作的地方会见开发人员，并帮助您轻松开发有效的工作流程最佳实践。
不幸的是，Git 利用率低是一个比您想象的更普遍的问题。无数人将 Git 用作代码的垃圾场，而不是管理良好的软件档案库。
这里有五个简单的提示，可以确保您通过这些 Git 工作流最佳实践充分利用 Git:
提示 1:提交消息就是一切
在下面展示的精彩 XKCD 网络漫画中，作者说“随着项目的拖延，提交信息变得越来越少。”
我们看到评论从描述性的“创建主循环和定时控制”下降到我的“手在打字”和“哈哈哈”的绝对混乱状态。乔想说这只是连环漫画中的一个笑话，但它可能太真实了。
在另一个例子中，他分享了一个 Twitter 用户的实际提交历史记录。
Dennis 在 Git 历史中浏览“有用的”提交消息来调查一个问题。很明显，这些提交消息没有提供足够的信息来知道在引入 bug 后从哪里开始查找。
想象一个场景，你在代码库中看到一些奇怪的东西，但是没有代码内注释。使用 Git 责备，您可以看到是谁修改了它，但是您会看到一条提交消息，上面只写着“test”不幸的是，做出改变的开发人员外出度假了，所以你不能立即找到他们改变背后的原因。现在，如果你改变了它，或者在别的地方破坏了某些东西，你就有重新引入一个 bug 的风险。相反，假设你看到了一段代码，自从你最后一次工作以来，它发生了变化，你对它现在的编写方式不满意。再一次，你利用 Git 责备，你看到一个提交消息，说“修复 chrome 中的日期格式问题。”在这种情况下，您最好保持原样。一个好的提交消息实际上救了你！
如果您想要编写一个好的提交消息并遵循 Git commit 最佳实践，提交消息应该像回答问题“这个提交做什么？”还可以考虑用动词开始提交消息。例如“修复恢复”或“集成服务”虽然这是一个很好的背景，但它本身是不够的，因为这些短消息仍然没有完全告诉我们在这些提交中发生了什么。
细节，细节，细节！
GitKraken 客户端为您的提交消息提供了两个字段:标题和描述。最好保持标题简短，不超过 72 个字符，并在描述字段中添加更多细节。
例如，“修复 Chrome 中的日期格式问题”比“修复提交消息标题的错误”要好得多。在提交消息描述中，您可以提供更多的细节。在描述中，你可以这样说:“Chrome 总是采用 MM/DD 格式，不管浏览器的区域设置是什么。”虽然这是一个虚构的 bug，但是这个例子说明了提交消息可以更加健壮和信息丰富。
为 Git 回复提供更多信息也是非常有用的。默认情况下，Git revert 生成的消息填充了提交消息标题:“revertslast commit message title”比如Reverts new “Paytastic Checkout” checkout flow。
如果我们添加描述“客户已经改变主意，希望恢复使用 LegacyCart ”,那么我们在顶部会有一个精彩的概述，在描述中会有更多的细节。
您也可以在命令行上添加提交消息描述。您只需要传入两个消息参数:
Git commit -m “Title” -m “Description”
将提交链接到问题
如果您有一个票务系统或待办事项列表，在提交消息中包含项目的标题或票证 ID 号有时会有所帮助。您甚至可以在描述中提供初始问题的链接。
如果你已经将 GitKraken 客户端连接到一个问题跟踪器，比如 GitHub Issues ，你可以输入搜索找到你想要处理的问题，右击该问题，为该问题创建一个 Git 分支。通过这种方式添加额外的信息非常容易，因此当您将来回到某个问题时，您可以很快看到围绕该提交发生的所有事情。所有这些都不需要工具之间的上下文切换！
提示 2:提交和推送，少而频繁
当谈到人们应该多久犯一次错误时，最有说服力的论点是“少而常”因为 Git 是你工作和进度的备份，所以只有在特性完成时才提交是没有意义的。提交部分完成的工作比什么都不做要有用得多。
尽管确保每个提交都处于可构建或工作状态是一个好的实践，但是只要您在提交消息中声明了这一点，让“正在进行的工作”提交不准备合并也是可以的。
“少而常”的策略也可以帮助您恢复不需要的功能。从一个更大的提交中提取一小块代码确实很痛苦，但是如果您只需要恢复一个小的更改，就会容易得多。
提示 3: Git 壁球
一个缺点是，所有那些“少量且经常”提交的消息可能会很快变得非常嘈杂。虽然较小的进行中的提交在本地是有帮助的，但是您不希望所有这些提交消息都出现在最终的 Git 历史中。清理历史的一个解决方案是合并多个提交，这就是 Git squash 动作的用武之地。挤压是 Git rebase 命令的一部分。
GitKraken Client 使选择您想要组合的多个提交变得非常简单，右键单击选择“挤压 x 个提交”，其中 x 是您选择的提交数。
注意不要掩盖你的错误！你的错误和你的返工讲述了一个故事。它们可以为未来的开发人员提供有价值的解释，同时也记录了您的学习成果。我们应该为这些感到骄傲，因为它显示了你在发展你的手艺。不要隐藏错误。用壁球来整理东西，而不是把东西扫到地毯下。
提示 4:使用 Git 分支策略
有许多 Git 分支策略;虽然 Joe 个人最喜欢的是 GitHub Flow，但是还有很多。无论您选择哪一种，Git 分支策略通常都遵循特性驱动的开发模式。您为您正在处理的每个特性创建一个分支，然后有一个特定版本的状态的一些概念。通常，一个 Git 分支或者一个标签会告诉你部署了什么以及在什么时候部署的。
确保一次只有一个人负责任何一个分支也是很常见的，所以如果你有两个人在处理一个特性，你最好将这个特性分解成子特性。这使得每个开发人员都可以有效地执行“少而多”的提交策略。
GitKraken 客户端具有高级功能，如合并冲突检测，当两个团队成员同时处理同一个文件时，它会提醒用户。与 Git 的合作从未如此之好。
仔细看看 GitHub 流分支策略，您会发现它涉及到为您的特性创建一个分支，该分支映射到一个 GitHub 问题。然后，您将您的提交添加到该分支，打开一个 GitHub pull 请求，引发一场讨论，然后一位同事对您的更改执行一次代码审查。
您可能会添加更多的提交，但是一旦那个 Git pull request 过程结束，您就可以部署这些更改以进行测试。一旦测试完成，每个人都满意了，你的代码就被合并到主分支中了。
有理由使用不同的工作流和 Git 分支最佳实践。各有各的优点需要考虑。选择一个作为你的基线，然后使它适应你的组织、你的需求和你的项目。无论你选择哪一个，关键是要有一个分支策略。
提示 5:使用 Rebase 和 Merge
在具有多个并发工作流的较大项目中，您可能会以混乱的分支和合并而告终。分支变得相互关联，很难跟踪发生了什么。GitHub 实际上在创建拉取请求时提供了三个选项:
- 创建合并提交
- 挤压和合并
- 重设基础并合并
“创建合并提交”是不言自明的。如果 pull 请求成功，只需将建议的分支及其变更直接合并到指定的目标分支中。这是最简单的选择，却留下了最乱的历史。
“压缩并合并”选项意味着你的整个特性被压缩到一个提交中，然后直接放到主分支或开发分支上。虽然它非常整洁，但是您丢失了许多关于何时、如何以及为什么进行代码更改的文档。这使得改变变得非常困难，也更难理解为什么会发生一些事情。
“rebase and merge”选项允许您在保持树整洁的同时避免丢失数据。这是乔最喜欢的选择。注意，如果你使用的是 Azure DevOps ，这个选项被称为“半线性合并”，但是它会产生相同的结果。
The “create a merge commit” is fairly self-explanatory. If the pull request is successful, just merge the suggested branch with its changes directly into the specified target branch. This is the simplest option, but it leaves the messiest history.
The “squash and merge” option means your entire feature gets squashed into one commit and then plopped straight onto the main or developed branch. While it’s very neat and tidy, you lose a lot of the documentation of when, how, and why code changes were made. This makes reversing changes very difficult and it’s harder to see why something might have happened.
The “rebase and merge” option allows you to avoid losing data while keeping the tree clean and tidy. This is Joe’s favorite option. Note that if you’re using Azure DevOps, this option is called “semi-linear merge,” but it generates the same result.
你可以跳到 GitKon 会议视频中的 22:26，听听 Joe 对这个选项更透彻的解释。
改写历史
对于技巧四和技巧五，您正在重写历史，不是作为一种粉饰历史暴行的行为，而是简单地改变已经被推送到 Git 存储库的内容。维护您的真实历史当然有它的好处，因为它对学习和代码审查很有用。如果你从不篡改你的历史，也不可能真的把它弄乱。但是，要知道，从长远来看，这种方法是以回购可读性为代价的。一个快速的整理过程会让整个历史更加清晰。
Rewriting History
推动你改写的历史
安全重写历史的关键是确保在开始篡改历史之前，你已经推送了你的库*。这可以确保您在外部服务器上有备份，并在推送前给您一个复查的方法。重要的是要注意:因为你正在改变历史，你将不得不执行一个强制推动。如果你正在使用 GitKraken 客户端，你会收到一个有用的弹出窗口，有一点警告，确定你真的想做一个强制推重写历史。
GitKraken 客户端让你轻松查看你的 Git 历史，制作和修改 Git 提交消息，挤压提交，利用 Git 让你的提交历史尽可能的好。像 Joe 一样，成为一个真正的 git，使用 GitKraken Client 轻松安全地使用世界领先版本控制系统的高级功能。今天免费下载 GitKraken 客户端！*
Pushing Your Rewritten History
The key to rewriting history safely is to make sure you’ve pushed your repository before you start messing with history. This ensures you’ve got your backup on an external server, and it gives you a way to double-check before you push. It’s important to note: because you’re changing history, you will have to perform a force push. If you’re using GitKraken Client, you will receive a helpful pop-up with a little warning, making sure you really want to do a force push rewriting history.
GitKraken Client makes it easy to see your Git history, make and amend Git commit messages, squash commits, and leverage Git to make your commit history the best it can be. Be like Joe and be a real git about your Git history, and use GitKraken Client to make it easy and safe to use the advanced functionality of the world’s leading version control system. Download GitKraken Client free today!
如何查看你的 Git 分支列表？Git 问题的解决方案
原文：https://www.gitkraken.com/learn/git/problems/git-branch-list
CLI 没有 GitKraken 提供的可见性。获得远程的即时上下文，包括远程分支和分叉，并查看谁正在对哪些文件进行更改。
最好的 Git 分支策略是什么？| Git 最佳实践
原文：https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy
Git 和其他版本控制系统让软件开发人员能够跟踪、管理和组织他们的代码。
特别是，Git 帮助开发人员与队友合作编写代码；将提交和分支等强大的功能与特定的原则和策略相结合，有助于团队组织代码并减少管理版本所需的时间。
当然，每个开发人员和开发团队都是不同的，都有独特的需求。这就是 Git 分支策略的用武之地。
我们将讨论三种相当流行的 Git 分支策略，每种策略都有各自的优点。最精彩的部分？这些工作流都不是一成不变的，可以而且应该进行修改以适应您的特定环境和需求。
请注意:这些原始策略中有许多都是指“主”分支，但我们选择使用“主”来代替。
无论您选择哪种分支策略，GitKraken 都可以通过预测合并冲突检测和应用内拉请求等功能，实现与 Git 的强大、更简单、更安全的协作。
Git 流分支策略
Git 流分支策略背后的主要思想是将你的工作隔离到不同类型的分支中。总共有五种不同的分支类型:
主要的
- 发展
- 特征
- 释放；排放；发布
- 修补程序
- Git 流程中的两个主要分支是主和开发。有三种类型的支持分支，具有不同的预期目的:特性、发布和热修复。
Git 流:利弊
Git 流分支策略有很多好处，但是也带来了一些挑战。
Git 流量的好处:
各种类型的分支使组织工作变得简单而直观。
系统开发过程允许有效的测试。
发布分支的使用允许您轻松地、持续地支持产品代码的多个版本。
- 各种类型的分支使组织工作变得简单而直观。
- Git 流的挑战:
- 根据产品的复杂程度，Git 流程模型可能会过于复杂，并减缓开发过程和发布周期。
由于开发周期长，Git flow 在历史上不支持持续交付或持续集成。
Git 流与 GitKraken
- 传奇的跨平台GitKraken Git GUIfor Windows，Mac，& Linux 有助于在高层次上简化和可视化 Git，并支持 Git 流分支策略。
- 由于开发周期长，Git flow 在历史上不支持持续交付或持续集成。
Git 流与 GitKraken
要用 GitKraken 初始化 Git 流，打开 repo，然后导航到Preferences → Gitflow来设置您的首选分支命名约定。GitKraken 将帮助您启动和完成特性、发布和修补程序分支。
GitKraken 提供了令人难以置信的 GitHub 集成、 GitLab 集成、 Bitbucket 集成和 Azure DevOps 集成，使其更容易与托管库一起工作。
GitKraken 使大大小小的团队都能够利用 Git 的真正力量，让您更清楚地了解谁在什么时候做什么，这样您就可以避免冲突并保护您的代码。
GitHub 流量分支策略
GitHub 流分支策略是一个相对简单的工作流，允许较小的团队，或者不需要支持多个版本的 web 应用程序/产品，来加速他们的工作。
在 GitHub 流中，主分支包含您的生产就绪代码。
其他分支，特性分支，应该包含新特性和 bug 修复的工作，并且在工作完成并被适当评审后，将被合并回主分支。
GitHub 流程考虑
Learn more about Git team features
在使用 GitHub 流分支策略时，有六个原则你应该遵守，以确保你维护好代码。
主分支中的任何代码都应该是可部署的。
为新工作从主分支创建新的描述性命名的分支，例如feature/add-new-payment-types。
将新工作提交给本地分支机构，定期将工作推送到远程机构。
要请求反馈或帮助，或者当您认为您的工作已经准备好合并到主分支中时，请打开一个拉动请求。
在您的工作或功能被审阅和批准后，它可以被合并到主分支中。
一旦您的工作被合并到主分支中，就应该立即进行部署。
GitHub 流:利弊
- 与其他 Git 分支策略一样，GitHub flow 也有一些亮点和不足。
- 受 GitHub 流程指南启发的自定义图像。
- 要请求反馈或帮助，或者当您认为您的工作已经准备好合并到主分支中时，请打开一个拉动请求。
- GitHub 流的好处
- 在本帖中我们讨论的三个 Git 分支策略中，GitHub 流是最简单的。
- 由于工作流的简单性，这种 Git 分支策略允许连续交付和连续集成。
这种 Git 分支策略非常适合小型团队和 web 应用程序。
与其他 Git 分支策略一样，GitHub flow 也有一些亮点和不足。
GitHub 流的挑战
这种 Git 分支策略无法同时支持生产中的多个版本的代码。
缺乏专门的开发分支使得 GitHub flow 在生产中更容易出现 bug。
GitLab 流量分支策略
- 在其核心，GitLab 流分支策略是一个明确定义的工作流。虽然类似于 GitHub 流分支策略，但主要区别在于根据情况添加了环境分支——即生产和预生产——或发布分支。
- 就像其他两个 Git 分支策略一样， GitLab flow 有一个主分支，其中包含可以部署的代码。然而，这些代码并不是发布版本的真实来源。
- 在 GitLab 流程中，feature 分支包含新功能和 bug 修复的工作，当它们完成、审查和批准后，将被合并回主分支。
GitHub 流的挑战
在发布周期中使用 GitLab 流程
- GitLab 流分支策略适用于两种不同类型的发布周期:
- 版本化发布:每个发布都有一个基于主分支的相关发布分支。Bug 修复应该首先合并到主分支中，然后再精选到发布分支中。
自定义图像灵感来自 GitLab 流程中的图像。
在其核心，GitLab 流分支策略是一个明确定义的工作流。虽然类似于 GitHub 流分支策略，但主要区别在于根据情况添加了环境分支——即生产和预生产——或发布分支。
2.连续发布:生产分支被用来包含部署就绪的代码，所以当代码准备好发布时，它被合并到生产分支中。
在 GitLab 流程中，feature 分支包含新功能和 bug 修复的工作，当它们完成、审查和批准后，将被合并回主分支。
git lab 流程的优势
与 Git 流分支策略相比，GitLab 流更简单。
GitLab 流比 GitHub 流分支策略更有组织性和结构化。
稍加修改后，GitLab flow 可以允许连续交付和版本化发布。
- 自定义图像灵感来自 GitLab 流程中的图像。
git lab 流程的挑战
GitLab 流不是最简单的 Git 分支策略。
GitLab 流不是最结构化的 Git 分支策略，这可能导致混乱的协作。
git lab 流程的优势
可视化提交和分支的能力将使您和您的团队对您的存储库的结构有一个新的理解，使日常的 Git 操作更加直观。
- GitLab 流比 GitHub 流分支策略更有组织性和结构化。
- 那么，哪个是最好的 Git 分支策略呢？
- 最终，哪个 Git 分支策略是最好的取决于您和您的团队的环境、产品和您的特定开发需求。
没有一种通用的 Git 分支策略，无论您最终选择哪一种，您都可以通过进一步的修改来优化它。
使用 GitKraken 开始使用 Git flow。免费下载 GitKraken Git GUI 。
- GitLab 流不是最结构化的 Git 分支策略，这可能导致混乱的协作。
- GitLab flow is not the most structured Git branching strategy which can lead to messy collaboration.
可视化提交和分支的能力将使您和您的团队对您的存储库的结构有一个新的理解，使日常的 Git 操作更加直观。
The ability to visualize your commits and branches will give you and your team a newfound understanding of your repository’s structure, making daily Git actions more intuitive.
Make Git Easier with GitKraken
那么，哪个是最好的 Git 分支策略呢？
最终，哪个 Git 分支策略是最好的取决于您和您的团队的环境、产品和您的特定开发需求。
没有一种通用的 Git 分支策略，无论您最终选择哪一种，您都可以通过进一步的修改来优化它。
使用 GitKraken 开始使用 Git flow。免费下载 GitKraken Git GUI 。
Get started with Git flow using GitKraken. Download the GitKraken Git GUI for free.
探索教室的 Git 分支模型
原文：https://www.gitkraken.com/gitkon/git-branching-model-classroom
https://www.youtube.com/embed/NgFekb1zDmg?feature=oembed
视频
在 2021 GitKon Git conference 的一场会议中，哈特福德大学的教授 Roy Vanegas 分享了他如何在课堂上使用 Git 和 GitHub。使用 Git，Roy 已经成功开发了可复制的 Git 分支模型，用于课堂友好的工作流、评分和分配作业的方法。
教师可以在更传统的课堂环境中使用这些策略，管理人员也可以使用这些策略来促进专业发展，技术兴趣小组的领导者可以使用这些策略来分享知识，等等。
GitKraken 通过 GitHub 教师工具箱为教师免费提供我们的 GitKraken Client Pro！PS:学生还获得免费资源！
Get GitKraken Free for Teachers
与 Git 和 GitHub 共享任务
创建一个“不在这里工作”的主 Git 分支
如果您想使用 Git 与学生共享作业，首先创建一个默认的本地 Git 存储库。接下来，创建一个名为“不要在这里工作”的 Git 分支，并将该分支推送到您在 GitHub 上的共享库。
您需要将新的“不要在这里工作”分支作为您的主分支。要在 GitHub 中做到这一点，你可以选择“设置”->“分支”->“主”->然后选择“不要在这里工作”->“更新”。
观看此视频跟随 Roy，了解他如何创建“不在此工作”分支并将其设置为默认。
确保你的主要分支机构的标题是“不要在这里工作”,这只是确保学生不会意外地开始在主要分支机构工作。最终，每个学生都将拥有自己的名字写在上面的 Git 分支，从而降低了破坏其他学生代码的风险。
将“不在此工作”分支变成新的“主”分支后，删除原来的主分支。您可以通过运行以下命令来实现这一点:
git branch -d main->-git push origin --delete main->-git push origin --delete main
或者，您可以重命名主分支，而不是创建一个新的分支。不管你如何完成这个，目标是有一个主分支，明确地指导学生不要在它里面做任何改变。
为每个学生创建一个 Git 分支
接下来，使用脚本收集学生数据，包括名字、姓氏和 GitHub 用户名。这将允许您为每个学生创建一个分支。使用这些信息来创建他们的分支将有助于避免两个学生使用相同名称时产生的混淆。
学生分支名称示例:linus-torvalds-linux-inventor
上图是一个虚构学生列表的示例，每个学生都有自己的分支。
最后，指导您的学生上网，访问项目，并分叉分支。每个学生将分支分入他们的 GitHub 帐户后，他们就可以开始工作了！
使用 Git 和 GitHub 提交作品
在布置作业时，你应该给出具体的指示，要求学生将项目作为一个主要文件上交。如果学生计划提交附加文件，这些文件必须是主文件的依赖项。这简化了浏览每个学生提交内容的过程，并使学生提交内容的评分速度更快。
当学生准备提交他们的作品时，他们提交一个 GitHub pull 请求。从教师的角度来看，这使得浏览和分析所有分支以确保它们是正确的变得非常容易。一旦准确性得到验证，教师就可以接受到共享的 GitHub 存储库中的 pull 请求。
将所有学生项目放在一个共享存储库中的另一个好处是能够在课堂上方便地展示学生作业的例子。你可以在同一台机器上展示尽可能多的项目，而不是让每个学生单独连接他们的电脑。
Git 教室中的协作
Git 课堂策略的另一个独特的好处是学生能够协作。虽然每个学生都必须上交自己的独特作业，但他们可以从其他同学的分支中寻找灵感。这确实有风险，因为老师必须相信他们的学生会实践荣誉制度，或者有制度来确保没有人滥用制度和直接抄袭作业。
参考其他人的工作并观察其他人如何解决问题的能力对于 Git 课堂工作流来说是一个巨大的好处。这不仅是一种有益的课堂实践，这种工作流程还模仿了现实世界中开发人员与其团队的互动方式，这使其成为一种理想的实践，为他们进入劳动力市场做好准备。
用 Git Diff 检测作弊
不幸的是，作弊和学术不诚实在许多课堂上发生，这要求教师建立保护措施和程序来检测这种行为。当使用 Git 和 GitHub 给学生项目评分时，可以运行一个脚本来检测分支之间的相似性。
要比较分支，运行git diff后跟每个分支名称，每个分支对应一个您想要评估的学生。该命令返回项目之间的所有差异，并允许教师快速确定是否发生了任何作弊行为。
如果命令显示了各种差异，很可能没有作弊，但是如果命令没有返回差异，很明显一个或多个有匹配项目的学生作弊了。这个过程快速、方便，并且允许指导者清楚地识别作弊是否已经发生。
独特作品的例子
检测到作弊的例子–无差异
GitKraken 客户端中的 diff 工具使您能够做出更明智的决策，因此您可以执行高级 Git 操作，如 rebase，功能更强大，风险更低。
与 Git 和 GitHub 分享示例
在课堂上展示和分享例子是开始使用 Git 课堂工作流的最有说服力的理由之一。想象一下:每天来上课时，学生们在他们的机器上启动 GitHub 桌面，或另一个 Git 客户端，如 GitKraken 客户端，并打开与当天讲座相关的范例库。每当老师对示例回购进行新的修改时，学生们可以执行 Git pull 并立即在他们的电脑上看到示例。
这种共享代码示例的过程有一些主要的优点。学生可以实时查看代码，而不是努力写出错综复杂的代码行和复杂的命令。该工作流程还允许教师通过让学生自己进行 Git 提交来添加到示例中，从而强化学习原则。
概括来说，学生应该在到达教室后执行以下步骤:
- 启动他们的 Git 客户端，比如 GitKraken 客户端
- 启动他们的代码编辑器
- 通过拉、取和刷新来更新他们的示例副本
这种工作流程的最大优势在于它给学生提供了更多的时间来记下代码及其背后的原理，而不是试图跟随并逐字逐句地复制随机代码。
轻松归档存储库以备将来使用
使用这种 Git 工作流的一大优势是归档存储库非常方便。一旦教师结束了一节课，他们可以将存储库标记为私有，并保留它，直到他们在未来的课上再次需要它，或者出于其他目的需要引用它。这个工作流程为所有事情创建一个记录。讲师使用的每一堂课、每一个例子和每一个其他资源都可以很容易地保存下来，供将来参考。
事实上，最近另一所大学的一位教授联系了罗伊，请他帮忙找出一个可能是以前的学生学术欺诈的例子。Roy 能够浏览旧的成绩和作业，并很快收集到另一位教授要求的信息，即使这位学生已经很久没来上课了。
克服 Git 学习曲线
Git 的学习曲线可能会很陡，如果学生从未使用过类似的技术，学习起来可能会特别困难。从教师的角度来看，教学可能很有挑战性。虽然您可以进行深入的讲座，但从根本上来说，Git 可能是一个令人困惑的学习系统。
认识到这一点很重要，Git 教室的工作流程是一种完全不同的使用 Git 的方式，不同于你在私营部门中常见的任何方式。即使是有经验的 Git 用户，在开始时也很难习惯这种独特的项目设计。
但是随着时间的推移，有了足够的有用资源，你和你的学生可以克服学习 Git 的挑战。
Git 的学习曲线可能会很陡，但是花时间去理解 Git 概念将会在未来的几年中对你大有裨益。GitKraken 的学习资源将帮助您和您的团队了解基础知识和高级操作，让您对工作流程更有信心。
工作时的时间戳
在课堂上使用 Git 的另一个好处是能够通过时间戳查看学生何时完成、完成和提交作业。比方说，你有一个不接受任何迟交作业的政策，但是一个学生坚持说他们因为某种原因不能提交。
您可以很容易地查看他们的系统，并运行一些类似于git log的命令来查看最后一次提交是何时执行的，并将该信息与指定的到期日期进行比较。在与学生一起工作时不可避免地会出现各种复杂的情况，在工作中使用时间戳会很有帮助。
在 Git 中搜索大型项目可能会很复杂
在课堂上使用 Git 有一些缺点。首先，很难找到学生上交的文件。如果您在本地操作系统上使用内置搜索来查找特定文件，您需要确定您正在哪个分支上工作。
同时搜索文件和分支会很快变得复杂。这就是为什么需要熟练理解如何使用 Git 命令行来接受这种方法，这对于不熟悉 Git 的人来说是很困难的。
使用 Git 和 GitHub 访问课程材料
如果学生错过了课程，他们仍然可以访问他们错过的代码和课程材料。他们只需访问 GitHub 上的类库，更新他们的本地类库，当天共享的任何代码现在都可以在他们的本地机器上获得。
虽然每个教师可能有不同的出勤政策，但至少使用这种模式，学生有能力跟上课程材料。
实施 Git 课堂模型
概括地说，Git 课堂工作流程遵循以下大纲:
- 给每个学生分配他们自己的 Git 分支
- 教师在课堂上使用 GitHub repo 示例展示示例
- 学生通过提交 GitHub pull 请求来提交作业
- 学生通过查看彼此的项目来相互协作和学习
- 教师用 Git 和 GitHub 对提交的内容进行评分和比较
虽然在 Git 的密集学习曲线下，这可能是一个很难实现的过程，但如果正确利用，这个工作流对学生和教师来说都会变得非常有效。允许学生在课外查看来自同龄人和教师的示例，可以确保课堂上的时间用于提问和深入材料，而不是简单地捕捉表面笔记。最终，在课堂上使用 Git 模型可以创建一个身临其境的动手环境，让学生真正学习 Git。
如果你正在寻找更多的方法来教学生如何使用 Git，试试 GitKraken 客户端。这款传奇的 Git 工具以其漂亮的视觉效果、直观的操作和团队功能使学习 Git 变得简单——此外，还可以查看给学生和教师的免费资源。👀
你如何签出一个提交？Git 问题的解决方案
原文：https://www.gitkraken.com/learn/git/problems/git-checkout-commit
每当您想要检查特定行为何时被引入到代码中时，检查提交可能是完美的解决方案。
在向您展示如何在命令行中执行操作之前，我们将介绍如何使用跨平台 GitKraken 客户端来执行 Git checkout 提交。
使用 GitKraken 客户端，只需点击两次即可完成结帐。
如何用 GitKraken 检查提交？
在 GitKraken 中检查提交既快又简单。只需右键单击中间图形中的提交，并从上下文菜单中选择Checkout this commit。
是的，就是这么简单。
用 GitKraken 检查提交时不需要提交散列。💥
如何在命令行中检查提交？
要检验 Git 提交，您将需要提交散列。如果您使用的是终端，那么您无法直接看到您的提交信息。要调出提交及其相关散列的列表，可以运行git log命令。
用 GitKraken 检查提交时不需要提交散列。💥
如何在命令行中检查提交？
要检验以前的提交，您将使用 Git checkout 命令，后跟从 Git 日志中检索到的提交散列。
Psst:我们知道你正在做一些重要的事情…你可能只是想完成你的行动，然后继续前进…但是把这个页面加入书签，稍后看看 GitKraken 客户端终端中令人难以置信的自动建议和自动完成功能。
git checkout <commit hash>
使用适用于 Windows、Mac 和 Linux 的 GitKraken Client 使检查提交的过程变得更加容易。可视化上下文允许您只需点击两次就可以签出提交，而不用担心散列。
如何用 GitLens 检查提交？
如果你在 VS Code 上安装了 GitLens，打开一个 repo，然后点击活动栏上的源代码控制图标。
展开提交视图，右键单击任何提交以访问 Switch to Commit 操作。
如何用 GitLens 检查提交？
这将有效地在分离的 HEAD 状态下检验提交，类似于上面的 GitKraken 客户端和 CLI 选项。
或者，有一个有用的 GitLens 特性，可以帮助您在任何时候浏览作为虚拟文件夹的存储库。右键单击提交视图中的任何提交，但是这次单击**Browse**子菜单。
这将允许您从指定的时间点打开一个新的 VS 代码窗口，而无需正式签出分支或提交。
如果你想亲自体验一下这个功能，请进入 VS 网页代码，安装 GitLens 试试看！
GitLens 可以帮助您保持组织性，并跟踪您的任务和项目。免费解锁 VS 代码中 Git 的全部功能！
这将允许您从指定的时间点打开一个新的 VS 代码窗口，而无需正式签出分支或提交。
如果你想自己检验这个特性，跳到 VS 代码网站并安装 GitLens 来试试吧！
GitLens 可以帮助您保持组织性，并跟踪您的任务和项目。免费解锁 VS 代码中 Git 的全部功能！
Install GitLens for VS Code
你如何检查一个 Git 标签？Git 问题的解决方案
原文：https://www.gitkraken.com/learn/git/problems/git-checkout-tag
在 Git 中，标签是指向特定时间点的引用，通常用于标识代码的发布版本。
在向您介绍如何在 CLI 中签出一个标记之前，我们将讨论如何使用跨平台 GitKraken Git 客户端来签出一个 Git 标记。
如何用 GitKraken 结账？
在 GitKraken 中，您可以立即看到存储库中的所有标签，它们清楚地列在主 UI 的左侧面板中。你也可以从这个位置过滤和搜索标签，这对于大的转发来说特别方便。
要在 GitKraken 中签出一个标签，只需在中间的图中右键单击一个标签，这里的标签用🏷标签图标。从这里，您可以选择Checkout this commit以分离的头部状态检出标签。
使用 GitKraken，只需点击 2 次，即可将标签签出为提交或分支。
如何使用 GitKraken 将标签签出为分支？
要将 Git 标签作为 GitKraken 中的一个分支签出，右键单击左侧面板或中央图中的标签，并从上下文菜单中选择Create branch here。
使用 GitKraken 更自信地快速识别和检查标签。
如何在终端中检查 Git 标签？
如果你使用命令行，你将看不到你的标签列表整齐地排列在你的用户界面的左边，就像你在 GitKraken 看到的那样。要查看 Git 存储库中存在哪些标签，可以运行git tag命令来查看 Git 标签的列表。
从这里，您可以在分离的 head 状态或作为分支签出标签。让我们从如何在分离的 head 状态下签出 Git 标签开始。这可以通过以下方式实现:
git checkout <tag name>
如何在终端中将 Git 标签签出为分支？
或者，您可以使用以下代码将 Git 标记作为分支签出:
git checkout -b <branch name> <tag name>
使用传说中的 GitKraken Git GUI 检查标签是无缝和直观的，并让您对您的工作流程有更多的控制。今天免费下载。
Git 签出-签出分支、提交和标签|学习 Git
Git checkout 命令告诉 Git 您希望您的更改应用到哪个分支或提交。
现在，在我们开始讨论如何在 GitKraken Git 客户端和命令行中进行 Git 检验之前，让我们先快速复习一下 Git 分支和 Git 提交。
在 Git 中，分支是指向一个特定提交的指针，而提交是您的存储库在特定时间点的快照。
您的分支指针随着您的每次新提交而移动。
在 GitKraken 中，您可以快速识别分支和相关提交，使签出变得轻而易举。
Git 检验分支
如果要对尚未签出的分支进行更改，首先需要签出该分支。
GiTip:学习如何 Git 结账一个远程分支以及如何在本地分支之间切换。
检出 Git 分支将更新您的存储库文件，以匹配分支指向的任何提交的快照。从这里开始，分支指针将继续跟随分支上的每个新提交。
Git 签出提交
也有可能 Git checkout 提交。这将更新您的存储库文件，以匹配您签出的提交的快照。这对于在不创建新分支的情况下审查旧的提交非常有用。
GitTip:如果你想了解更多关于如何 Git checkout 一个 commit 的知识，我们可以指导你。
Git Checkout Tag
类似地，如果你想回顾过去的代码版本，比如最近发布的版本，你可以签出一个标签。
GitTip:了解更多关于如何用 GitKraken 和命令行检查 Git 标签的信息。
Git 分离头
注意这一点很重要:检查 Git 提交或 Git 标签会将头点移动到提交而不是分支。这将使您的存储库处于所谓的分离状态。
当您在 Git 中处于分离的 HEAD 状态时，您不能提交对分支的更改。
Git 结帐的好处
Git checkout 对于将更改应用到分支非常有用，但是如果您想要检查某个行为是何时引入的，它对于检查旧的提交也很有用。
注意这一点很重要:检查 Git 提交或 Git 标签会将头点移动到提交而不是分支。这将使您的存储库处于所谓的分离状态。
你如何用 GitKraken 结账？
无论您是想使用 Git checkout 命令来检查分支、提交还是标记，GitKraken 都可以让整个过程变得简单直观，并提供整个存储库的完整可视上下文。
厌倦了浪费时间搜索提交散列或标记名吗？GitKraken 可以帮忙。
Git checkout 对于将更改应用到分支非常有用，但是如果您想要检查某个行为是何时引入的，它对于检查旧的提交也很有用。
你如何用 GitKraken 结账？
在这个例子中，我们将回顾如何使用 Git checkout 命令来签出一个远程分支。
由于 GitKraken 主用户界面提供的视觉优势，您可以查看左侧面板中列出的所有远程分支机构。
要在 GitKraken 中签出远程分支，只需双击或右键单击左面板或中央图中的分支名称，然后选择Checkout。
你如何用 GitKraken 结账？
或者，您可以使用 GitKraken 模糊查找器，方法是键入“checkout ”,然后键入您想要检查的分支名称。
由于 GitKraken 主用户界面提供的视觉优势，您可以查看左侧面板中列出的所有远程分支机构。
如何用 GitKraken 检查提交？
GitKraken 在中央图表中按时间顺序显示您的存储库的提交列表。要在 GitKraken 中检查一个提交，右键单击中央提交并选择Checkout this commit。
你如何用 GitKraken 签出标签？
在 GitKraken 中，标签在中央图形中用🏷标签图标。这使得快速和容易地找到您的回购标签。
在中间的图表中，找到您想要签出的标签，然后右键单击。然后，选择Checkout this commit以分离头部状态检出标签。
你如何用 GitKraken 签出标签？
但是，如果您想将标签签出为分支，该怎么办呢？您可以遵循完全相同的过程，但是在中间图形或左侧面板中右键单击目标标记后选择Create branch here。
只需点击两次，您就可以在 GitKraken 中签出分支、提交或标记。🤯
如何在命令行中签出一个分支？
如果您正在使用 CLI，您将无法立即看到您的本地分支，因此您将从运行 Git branch 命令来查看您的本地分支列表开始。这也将显示您当前已经签出的分支。
接下来，您将运行 Git checkout 命令，后跟您希望切换到的本地分支的名称。
如何在命令行中检查提交？
为了在 CLI 中检查提交，您将需要提交散列。您可以通过运行 Git log 命令来获得提交散列。
要检验之前的提交，您将使用 Git checkout 命令，后跟提交散列。
git checkout <name-of-branch>
如何在命令行中签出一个标签？
与 GitKraken 不同，在 Git kraken 中，您可以通过在中心图中查找标记图标来轻松定位您的标记，您必须运行 Git tag 命令来查看您的存储库的标记列表。
有了标记名之后，可以在 Git 分离头状态下签出标记，或者将标记作为分支签出。如果您想在分离的 HEAD 状态下签出标签，您将运行:
git checkout <commit hash>
如果您想将 Git 签出标记作为分支，您将运行:
你的时间和精力是宝贵的；为什么要花时间去记忆或查找远程分支、提交散列或标记名呢？让传说中的跨平台 GitKraken Git GUI 为您组织所有这些，并以一个漂亮且易于理解的图形呈现您的存储库。
有了标记名之后，可以在 Git 分离头状态下签出标记，或者将标记作为分支签出。如果您想在分离的 HEAD 状态下签出标签，您将运行:
git checkout <tag name>
如果您想将 Git 签出标记作为分支，您将运行:
git checkout -b <branch name> <tag name>
你的时间和精力是宝贵的；为什么要花时间去记忆或查找远程分支、提交散列或标记名呢？让传说中的跨平台 GitKraken Git GUI 为您组织所有这些，并以一个漂亮且易于理解的图形呈现您的存储库。
去克隆区
原文：https://www.gitkraken.com/learn/git/problems/git-clone-branch
在开始使用 Git 中现有的项目存储库之前，首先需要在您的机器上创建项目的本地副本。这就是 Git 克隆命令的用武之地。
Git 克隆动作将一个现有的 远程 Git 库的副本下载到您的机器上，包括所有的分支。默认情况下，Git 将在新的本地存储库中检出原始 repo 的主分支。
GitTip:获得关于 如何结帐远程 Git 分支的分步教程。
为什么要 Git 克隆一个分支？假设您想要立即开始某个特定分支的工作，那么您想要克隆远程并同时签出该分支。或者也许您不需要克隆整个存储库，因为您只负责一个分支，所以您只想要 Git 克隆分支。
输入 Git 克隆分支。
Git 克隆分支命令提供了两个主要功能:
- 克隆整个远程存储库，然后签出并设置特定分支的上游。
- 仅克隆指定的分支，然后检出并设置该分支的上游。
在这个 Git 克隆分支的例子中，我们将回顾如何使用跨平台 GitKraken Git 客户端来克隆 Git 分支，然后在 CLI 中完成整个过程。
如何使用 GitKraken 克隆一个分支？
与命令行不同，GitKraken Git GUI 提供了令人难以置信的可视性，因此您可以轻松地管理您的遥控器，并确切地看到克隆过程中发生了什么。
如何使用 GitKraken 克隆一个存储库并检出一个特定的分支？
首先打开一个新标签(+)并选择 UI 左侧的Clone a repo选项。
也可以使用键盘快捷键:Ctrl/Cmd + O，选择Clone。然后，您将选择您的集成远程托管服务:GitHub、GitLab、Bitbucket 或 Azure DevOps。
在这个 Git 克隆分支示例中，我们将对远程 GitHub 存储库使用Clone with URL选项。
在开始之前，您需要仔细检查以下字段:
- 您希望克隆到的目录
- 新本地目录的名称
如果一切正常，您将点击Clone the repo!按钮。
成功克隆存储库之后，您只需在左侧面板中双击您想要签出的分支。
因为 CLI 没有您需要的可见性，您浪费了多少时间来克隆错误的分支？GitKraken 会照亮道路。
如何在命令行中克隆一个分支？
在使用 can Git 克隆分支之前，您需要两条信息:
- 托管远程存储库的 URL
- 要克隆和签出的分支的名称
在这个 Git 克隆分支示例中，我们将使用一个公共的 GitHub 存储库，并将克隆 Git 分支:Development。
如何在命令行中克隆一个库并检出一个特定的分支？
首先，您将导航到您希望克隆遥控器的本地父目录，在本例中为:/projects。
如果需要创建一个新的本地目录，可以使用:
mkdir <directory-name>
接下来，您将使用 Git clone branch 命令:
git clone --branch <branch-name> <repository-url>
(-b也代替这里的--branch工作)
如果执行正确，Git 将获取所有分支，并立即检出指定的分支。
通过我们在 GitHub 上的交互式实践库，直接掌握 Git 中克隆的诀窍。
如何在命令行中克隆一个特定的分支？
如果您只希望 Git 克隆一个分支，而不是远程存储库的其他内容，那么您将再次导航到您希望克隆远程存储库的本地父目录。
接下来，您将键入:
git clone --branch <branch-name> --single-branch <repository-url>
这将只从远程获取特定的分支。
因为 CLI 缺乏 GitKraken 所提供的可见性，所以您不能轻易地确认您是否克隆了预期的 Git 分支。
如果您希望验证您的 Git 克隆分支操作是否成功获取了目标分支，您可以运行:
git remote show origin
如果您想节省时间，在克隆一个 repo 后就开始处理分支，那么 Git clone branch 命令是一个非常有用的工具。另一方面，只克隆一个 Git 分支可以通过只从远程获取您需要的数据来帮助增强您的注意力。
GitKraken 主界面左侧的远程面板可以帮助您准确地看到您可以访问哪些远程分支，这样您就不必记住分支名称列表，从而节省您的时间和精力。现在使用 GitKraken Git 客户端简化常见操作，如克隆遥控器和分支。
Git 克隆|创建现有 Git 存储库的副本
更新日期:2022 年 6 月 15 日
Git clone 用于将现有的 Git 存储库复制到一个新的本地目录中。
Git clone 命令将为存储库创建一个新的本地目录，复制指定存储库的所有内容，创建远程跟踪分支，并在本地签出一个初始分支。默认情况下，Git clone 会创建一个对名为origin的远程存储库的引用。
如何 Git 克隆一个仓库
要 Git 克隆存储库，请导航到您喜欢的存储库托管服务，如 GitHub，选择您想要克隆的存储库，通过 HTTPS 或 SSH 复制存储库 URL，在命令行中键入git clone，粘贴 URL，然后点击enter。
克隆一个存储库允许您在提交和将它们推送到远程存储库之前，对存储库进行本地更改。
这对于初学者来说尤其有益，因为克隆给了你一个实验的沙箱，而不会影响原始代码库(也不会激怒你的团队成员)😅).在本文中，我们将深入了解如何从 GitKraken 客户端的命令行以及 GUI 中进行 Git clone。
涵盖 Git 克隆主题
Git 远程协议
如何使用 GitKraken 客户端通过 SSH 进行 Git 克隆
如何使用 GitKraken 客户端在 HTTPS 上进行 Git 克隆
不要冒险损害代码的安全性。GitKraken 客户端允许安全连接到远程存储库——这是您不用担心的一件事。
Git 远程存储库 URL 协议
Git 中支持的远程 URL 协议有 SSH、Git、HTTP 和 HTTPS。
Git SSH 远程协议
SSH 代表安全外壳。使用 Git SSH 允许您使用密钥向远程存储库进行身份验证。
SSH URL 的格式:ssh://{user}@{host}:{port}/path/to/repo.git或{user}@host:path/to/repo.git
要在命令行中使用 Git SSH ，您需要生成一个公共和私有的 SSH 密钥，将密钥添加到您的 SSH-agent 中，并将公共密钥添加到远程托管服务中。
Git 远程协议
Git 协议是一种未经身份验证的方法，应该谨慎使用。
Git URL 的格式:git://{host}:{port}/path/to/repo.git
HTTP(S)远程协议
HTTP(S)代表超文本传输协议(安全)。通过使用 HTTPS，您可以使用用户名和密码凭证向存储库进行身份验证。
与 HTTP 相比，HTTPS 是一个更安全的版本。
HTTPS 网址的格式:https://{host}:{port}/path/to/repo.git
GitTip:通过我们的 Git 初学者教程视频系列，了解更多关于本地 Git 仓库和远程仓库的信息。
使用 GitHub 练习报告，跟随 GitKraken 客户端和命令行中即将出现的克隆示例。
HTTP(S)代表超文本传输协议(安全)。通过使用 HTTPS，您可以使用用户名和密码凭证向存储库进行身份验证。
如何使用命令行在 HTTPS 上进行 Git 克隆
在这个例子中，我们将回顾在 HTTPS 克隆 GitHub 库的过程。要克隆 Git 存储库，首先要从存储库托管服务复制远程 URL 在本例中是 GitHub。
GitTip:通过我们的 Git 初学者教程视频系列，了解更多关于本地 Git 仓库和远程仓库的信息。
使用 GitHub 练习报告，跟随 GitKraken 客户端和命令行中即将出现的克隆示例。
然后，您将使用 Git clone 命令，后跟远程 repo 的 URL。
如何使用命令行在 HTTPS 上进行 Git 克隆
如果您使用的是私有存储库，系统会提示您输入远程托管服务凭据。
克隆之后，您可以将目录(cd <path>)更改到存储库中，开始在其中工作。有许多额外的标志可以在克隆时使用，比如命名本地目录、命名远程目录或检查分支。
然后，您将使用 Git clone 命令，后跟远程 repo 的 URL。
git clone <repository-url>
如何使用 GitKraken 客户端通过 SSH 进行 Git 克隆
如果在 GitKraken 客户机上使用 URL 通过 SSH 克隆，首先需要在 Git 客户机上配置 Git SSH。GitKraken 客户端有一个内置的 SSH 代理，使得使用 SSH 密钥(包括 GitHub SSH 密钥)变得非常容易。
您的 GitKraken 客户端 SSH 设置可以在Preferences > SSH下找到。在这里，您可以生成一个新的 SSH 密钥，指向一个现有的密钥，或者使用本地 SSH 代理来管理 SSH。
如果这是您第一次通过 GitKraken 客户端使用 SSH，您需要将 SSH 密钥添加到远程托管服务——在本例中是 GitHub。您只需从 GitKraken 客户端复制公钥，并将其添加到托管服务的设置部分。
克隆之后，您可以将目录(cd <path>)更改到存储库中，开始在其中工作。有许多额外的标志可以在克隆时使用，比如命名本地目录、命名远程目录或检查分支。
如何使用 GitKraken 客户端通过 SSH 进行 Git 克隆
完成这些步骤后，您将能够简单地提供 SSH URL 来用 GitKraken 客户端克隆远程存储库。
您的 GitKraken 客户端 SSH 设置可以在Preferences > SSH下找到。在这里，您可以生成一个新的 SSH 密钥，指向一个现有的密钥，或者使用本地 SSH 代理来管理 SSH。
有关在 GitKraken 客户端使用 SSH 的更多信息，请参见我们的 Git SSH 文档。GitHub 也为如何使用 SSH 提供了很好的指南。
如何使用 GitKraken 客户端在 HTTPS 上进行 Git 克隆
如果你用 GitKraken 客户端使用 URL 来克隆 HTTPS，你只需在提示时提供远程 URL。
有关在 GitKraken 客户端使用 SSH 的更多信息，请参见我们的 Git SSH 文档。GitHub 也为如何使用 SSH 提供了很好的指南。
在这里，您还将设置克隆的本地路径和本地存储库目录名。
如何使用 GitKraken 客户端在 HTTPS 上进行 Git 克隆
Git 克隆与 GitKraken 客户端集成
GitKraken Client 为以下远程存储库托管服务提供集成，使克隆和许多其他操作变得更加简单:
如下所示，您连接到 GitKraken 客户端帐户的每个主机服务集成将列出所有可用于克隆的远程存储库。
HTTPS 是 GitKraken 客户端的默认远程协议。在连接到您的远程存储库托管服务之后，在 HTTPS 上工作时，您将不需要填写凭据，因为集成使用 OAuth 或 PAT(个人访问令牌)进行身份验证。
GitKraken Client 为以下远程存储库托管服务提供集成，使克隆和许多其他操作变得更加简单:
对于这些集成中的每一个，您都可以快速创建一个 SSH 密钥或指向一个现有的密钥。生成一个 SSH 密钥会自动将它添加到托管服务中，不再需要从一个平台手动复制它并将其添加到另一个平台。
您可以通过导航至Preferences > Integrations随时管理您的 GitKraken 客户端集成。在这个例子中，您可以看到 GitKraken 客户端正在创建一个 GitHub SSH 密钥。
HTTPS 是 GitKraken 客户端的默认远程协议。在连接到您的远程存储库托管服务之后，在 HTTPS 上工作时，您将不需要填写凭据，因为集成使用 OAuth 或 PAT(个人访问令牌)进行身份验证。
或者，如果您想指向一个现有的 SSH 密钥，您可以通过单击将公共 SSH 密钥添加到托管服务中。
对于这些集成中的每一个，您都可以快速创建一个 SSH 密钥或指向一个现有的密钥。生成一个 SSH 密钥会自动将它添加到托管服务中，不再需要从一个平台手动复制它并将其添加到另一个平台。
测试你的新技能，并使用这个指导性的 GitHub repo 练习用 GitKraken 克隆一个库。
常见问题
问:如何克隆 Git 存储库
答:如果您想要克隆一个现有的 Git 存储库，请在您喜欢的代码托管服务(如 GitHub 或 GitLab)上导航到您想要克隆的 repo，并选择 clone with SSH 或 HTTPS。
问:如何克隆 Git
答:Git 是一个分布式版本控制软件，允许你跟踪项目。您不太可能会遇到想要克隆 Git 本身的情况。相反，使用 Git，您可以通过 SSH 或 HTTPS 从 GitHub、GitLab 等托管服务中克隆一个存储库。如需更多高级克隆选项，如使用 Git clone-shared、Git clone-no check out 等，请访问 Git SCM 。
测试你的新技能，并使用这个指导性的 GitHub repo 练习用 GitKraken 克隆一个库。
GitKraken 客户端使 Git 克隆更容易
你的 Git 投资组合越多，管理你的远程回购库就越难。GitKraken Git client 可以帮助您组织来自多个托管服务的远程信息，让您能够快速找到并克隆您需要的回购。
问:如何克隆 Git 存储库
答:如果您想要克隆一个现有的 Git 存储库，请在您喜欢的代码托管服务(如 GitHub 或 GitLab)上导航到您想要克隆的 repo，并选择 clone with SSH 或 HTTPS。
问:如何克隆 Git
答:Git 是一个分布式版本控制软件，允许你跟踪项目。您不太可能会遇到想要克隆 Git 本身的情况。相反，使用 Git，您可以通过 SSH 或 HTTPS 从 GitHub、GitLab 等托管服务中克隆一个存储库。如需更多高级克隆选项，如使用 Git clone-shared、Git clone-no check out 等，请访问 Git SCM 。
A: Git is a distributed version control software that allows you to track projects. It is unlikely that you will run into a situation where you would want to clone Git itself. Instead, using Git, you can Git clone a repository from a hosting service like GitHub, GitLab, and others via SSH or HTTPS. For more advanced cloning options like using git clone –shared, git clone –no checkout, and more, visit Git SCM.
GitKraken 客户端使 Git 克隆更容易
你的 Git 投资组合越多，管理你的远程回购库就越难。GitKraken Git client 可以帮助您组织来自多个托管服务的远程信息，让您能够快速找到并克隆您需要的回购。
The more your Git portfolio grows, the harder it will be to manage your library of remote repos. The GitKraken Git client can help organize your remotes from multiple hosting services, giving you the ability to quickly find and clone the repo you need.
基于 Git 的 CMS 与 API 驱动的 CMS
内容管理正转向两种无头选项:基于 Git 的和 API 驱动的。Headless CMS 解决方案允许开发人员轻松地编辑和管理内容，同时仍然使用他们熟悉和喜爱的前端和后端工具和平台。这些基于 Git 和 API 驱动的 CMS 解决方案为开发人员提供了一种新的方式来加快 CI/CD 流程，而不会影响产品质量。
Git 是初学者和经验丰富的软件开发人员的必备工具。根据我们最近的调查，95%的受访者在他们当前的项目中积极使用 Git。因此，基于 Git 的 CMS 可以对开发人员和团队产生巨大的影响。希望学习 Git 并快速发展可行的技能吗？查看我们学习 Git 的顶级资源。
但是 API 驱动的 CMS 对于新老开发者也有优势。基于 Git 的 CMS 充当 Git 之上的一层，直接与 Git 存储库交互，而 API 驱动的 CMS 使用户能够选择他们想要使用的框架和语言。哪个适合你？让我们讨论一下每种类型的优点、缺点、好处和挑战，这样你就可以决定哪种最适合你。
什么是无头 CMS？
像 WordPress 和 Drupal 这样的传统 CMS 被构建在一个单一的 web 优先的应用程序中，具有后端和前端功能。由于全球注册了超过 3 . 6 亿个域名，传统的 CMS 通常足以满足初露头角的开发者和那些几乎没有编码知识的人的需求。
像 WordPress 和 Drupal 这样的传统 CMS 被构建在一个单一的 web 优先的应用程序中，具有后端和前端功能。由于全球注册了超过 3 . 6 亿个域名，传统的 CMS 通常足以满足初露头角的开发者和那些几乎没有编码知识的人的需求。
无头解决方案为专业开发人员提供了对其实现的更多控制，并使团队能够创建更加一致的 CI/CD 管道。它还使团队能够跨多个前端重新调整内容的用途。Headless CMS 将内容管理与前端表示层分离，因此开发人员可以交付应用和网站之外的内容。
基于 Git 的内容管理系统
当使用基于 Git 的 CMS 时，开发人员实际上是在使用已经保存到他们的存储库中的文件。基于 Git 的 CMS 解决方案的行为就像 Git 之上的一个层，直接与 Git 存储库交互。一些最流行的基于 Git 的 CMS 包括林业、公共和散文，但是还有更多可供选择。
基于 Git 的内容管理系统
在我们深入探讨好处和挑战之前，让我们从高层次上看一下使用基于 Git 的 CMS 的利弊:
赞成的意见
内容的完整版本控制
内容以平面文件的形式存在，因此开发人员可以使用他们常用的工具
易于回滚
- 基于 Git 的工作流的同质方法
- 没有数据或带宽限制
- 易于设置
- 基于 Git 的 CMS 与 Git 存储库和开发人员已经在使用的工具无缝融合。因为它本质上是 Git 层之上的一层，所以除了写入代码的内容之外，实际上没有任何数据限制。
- 骗局
- 无法从使用相同 CMS 的多个应用程序和网站获取内容
有限的发布能力
不适合包含大量内容的网站
对内容格式的有限控制
存储库大小的限制意味着开发人员可能需要为媒体文件提供单独的服务
- 无法从使用相同 CMS 的多个应用程序和网站获取内容
- 尽管基于 Git 的 CMS 对于使用 Git 库进行开发的团队很有帮助，但是对于那些经常向他们的项目发布大型媒体文件的团队来说，它可能会稍微复杂一些。此外，内容格式化严格受限于 Git，这意味着它不能跨多个演示提取内容。
- 基于 Git 的 CMS 的优势
- 现在我们已经了解了一些基础知识，让我们了解更多关于使用基于 Git 的 CMSs 的好处。
- 多对象版本控制
传统的 CMS 平台在其构建能力方面受到限制。有限的版本意味着传统的解决方案必须维护繁琐的数据结构或跟踪单对象图。对于普通开发人员来说，有限的版本控制并不是一个障碍。
基于 Git 的 CMS 的多对象版本控制给组织带来了优势。在基于 Git 的解决方案的支持下，它允许在文件级别跟踪特定的内容变化。因为所有内容都存储为平面文件，所以可以很容易地从测试环境转移到开发和生产环境以及系统之间。
分布式存储库和分支
有了基于 Git 的 CMS，分布式版本管理和工作流管理都得到了简化。传统的 CMS 要求开发者直接在 CMS 中工作。但是基于 Git 的 CMS 开发人员可以在本地工作，并且仍然可以在 CMS 中进行修改。开发人员不用被迫使用中介工具，仍然可以不受限制地使用他们日常使用的工具。
通过分支，团队可以创建无限的阶段环境和预览，以可视化开发过程，并使团队工作更加容易。开发人员和作者可以使用基于 Git 的 CMS 来完成这一切。他们可以尝试新的功能，对网站进行重大改进，并管理内容分发。
所有权
最后，开发人员使用基于 Git 的 CMS 的最后一个主要好处是所有权。内容数据都存储在本地存储库文件中，因此默认情况下，开发人员是内容的唯一所有者。这意味着开发者可以自由地将内容从 CMS 转移到 CMS，而不会产生法律后果。事实所有权解决了许多常见的 Git 错误，这些错误是经验丰富的专业人员和新手开发者在传输和分发内容时经常犯的。
基于 Git 的 CMS 面临的挑战
基于 Git 的 CMS 允许开发人员处理他们的内容，但也有一些挑战需要注意。
基于 Git 的 CMS 中的关系
关系对于建模和检查内容非常重要。与当前基于 Git 的 CMS 解决方案相关的主要问题是，如果不加强监督和定期维护，它们往往太简单，容易出问题。
通过分支，团队可以创建无限的阶段环境和预览，以可视化开发过程，并使团队工作更加容易。开发人员和作者可以使用基于 Git 的 CMS 来完成这一切。他们可以尝试新的功能，对网站进行重大改进，并管理内容分发。
搜索引擎优化的特殊措施是必需的
SEO 对于在线品牌来说也是一个至关重要的因素，但是 Git 没有提供任何具体的支持来帮助改进技术 SEO。使用基于 Git 的 CMS 的开发人员想要提高他们的在线可见性，需要生成站点地图，有效地使用元标签，开放图形标签，以及使用移动友好的主题。
GitHub 不运行插件
开发人员在使用基于 Get 的 CMSs 时遇到的最大问题是 GitHub 不运行插件。虽然许多用 Git 编码的开发人员意识到了这一限制，并推出本地生成的内容来定制某些功能，但这确实会推迟发布时间。
API 驱动的 CMS
API 驱动的 CMS 是另一种通过 API 提供内容的无头 CMS。这允许开发人员将内容与表示完全分离。这意味着数据是结构化的，但如何处理这些内容取决于您自己。一些最流行的 API 驱动的 CMS 包括 Prismic 、 Ghost 和 Strapi 。但是正如基于 Git 的 CMSs 一样，有许多 API 优先的解决方案可供选择。
图像来源
关系对于建模和检查内容非常重要。与当前基于 Git 的 CMS 解决方案相关的主要问题是，如果不加强监督和定期维护，它们往往太简单，容易出问题。
以下是使用 API 驱动的 CMS 的利与弊的简要概述:
赞成的意见
在不同的应用程序和网站之间分发相同的托管内容
能够在多个前端使用内容
大多数是完全可定制的
轻松处理大量数据
包括资产管理功能
骗局
未集成到开发人员工作流中
存储和使用限制
重大变更严重依赖开发人员
API 驱动的 CMS 的优势
正如您所看到的，API 驱动的 CMS 比基于 Git 的 CMS 拥有更多的特性，但是对于某些实现来说，缺点可能大于优点。让我们仔细看看使用 API 驱动的 CMS 的好处。
现有生态系统
API 驱动的 CMS 解决方案越来越受欢迎的原因之一是它们与现有的生态系统集成得很好。最佳解决方案还通过使用 API 中适当的端点来帮助团队实施最佳实践并最小化错误。这意味着开发人员可以自由地集成 CRM、分析和自动化等工具，并随时删除它们。通过这种方式，一旦客户情绪发生变化，品牌就可以改变他们的数字体验和平台。
- 在不同的应用程序和网站之间分发相同的托管内容
- 通过几种不同的设备接触消费者
- API 驱动的 CMSs 还使组织能够连接到几个不同设备上的消费者。平板电脑、智能手机和其他支持物联网的设备正变得越来越普遍，因为它们通常比电脑和个人电脑便宜。但传统的 CMS 平台无法在设备层面提供定制化的体验。然而，当 API 被开发用于特定的接触点时，API 驱动的 CMSs 可以，使得定制实际上是无限的。
- 更快的内容再利用
- API 驱动的 CMS 将内容存储在一个中心位置，使其易于传递到任何渠道。内容创建者可以创建一个内容片段，然后使用 CMS 将其重新用于新的渠道、不同的设备和不同的受众。这对于采用全渠道营销方式、以数字为先的公司来说是一个巨大的优势。它节省了时间，并且消除了为每个频道创建全新内容的需要。
API 驱动的 CMS 面临的挑战
API 驱动的 CMS 有很多好处，但是也有一些挑战，开发者应该小心。
- 过于依赖网络开发人员
- API 驱动的 CMS 解决方案严重依赖开发人员来创建定制的前端。这意味着团队需要做更多的工作，并且需要改进营销和开发团队之间的沟通。
- 内容预览是个问题
API 驱动的 CMS 并不总是允许开发者在内容发布前预览内容。后端编辑器允许内容创建者将他们的内容直接输入到 API 中，但是在没有从用户的角度看到页面行为的情况下发布内容是具有挑战性的。这给错误留下了很小的空间，因此开发人员和创建者必须确保他们正在进行准确的更改。
费用
API 驱动的 CMSs 可能比传统的和基于 Git 的 CMS 解决方案更昂贵。即使开源 API 驱动的 CMS 也需要组织支付基础设施成本，如托管和 cdn，人员成本，如开发人员和质量保证工程师，以及生产成本，如维护和安全。
基于 Git 的 CMS 与 API 驱动的 CMS
关于基于 Git 的 CMS 和 API 驱动的 CMS，没有一个比另一个更好。这完全取决于您作为开发人员的需求、您所工作的团队的才能，以及您的客户所期望的产品结果。如果你独自工作或者和一个固定的团队一起工作，做出选择会很简单。但是涉及的人员越多，就越困难。
许多组织和开发人员在时间紧张和最后期限临近时选择外包软件项目。在这种情况下，成本可能是一个重要因素。大多数自由软件开发人员要求 150-275 美元一小时的报酬，这个价格会随着经验和专业知识而上涨。有许多不同价位的基于 Git 和基于 API 的 CMS 选项，因此您一定会找到一个符合您预算的选项。
然而，考虑你的内容是在两个选项之间做出决定的最好方法。这些无头 CMS 类型之间的主要区别在于内容的存储和使用方式。在决定哪种解决方案最适合您时，这是一个至关重要的驱动力。
如何选择
切换到无头 CMS 意味着在基于 Git 的解决方案和 API 驱动的解决方案之间做出选择。虽然每个项目都需要不同级别的定制，但是您的整个开发过程应该是相同的。如果您仍然试图决定哪个选项适合您和您的团队，请确保您有一个可靠的开发策略，该策略足够灵活以适应独特的项目需求，但又足够严格以提供 CI/CD 过程的结构。
扪心自问，我的技术水平如何？我的团队能有效地使用 API 工具吗？客户期望迭代多快？你最常用的存储库是什么？你的团队对各种编码语言的理解程度如何？现在再来看看这两种无头 CMS 选项的优缺点、好处和挑战。在您最终决定之前，在采用基于 Git 或 API 驱动的解决方案之前，请确保您理解了工具背后的技术。
API 驱动的 CMS 将内容存储在一个中心位置，使其易于传递到任何渠道。内容创建者可以创建一个内容片段，然后使用 CMS 将其重新用于新的渠道、不同的设备和不同的受众。这对于采用全渠道营销方式、以数字为先的公司来说是一个巨大的优势。它节省了时间，并且消除了为每个频道创建全新内容的需要。
API 驱动的 CMS 面临的挑战
API 驱动的 CMS 有很多好处，但是也有一些挑战，开发者应该小心。
过于依赖网络开发人员
API 驱动的 CMS 解决方案严重依赖开发人员来创建定制的前端。这意味着团队需要做更多的工作，并且需要改进营销和开发团队之间的沟通。
内容预览是个问题
API 驱动的 CMS 并不总是允许开发者在内容发布前预览内容。后端编辑器允许内容创建者将他们的内容直接输入到 API 中，但是在没有从用户的角度看到页面行为的情况下发布内容是具有挑战性的。这给错误留下了很小的空间，因此开发人员和创建者必须确保他们正在进行准确的更改。
费用
API 驱动的 CMSs 可能比传统的和基于 Git 的 CMS 解决方案更昂贵。即使开源 API 驱动的 CMS 也需要组织支付基础设施成本，如托管和 cdn，人员成本，如开发人员和质量保证工程师，以及生产成本，如维护和安全。
API-driven CMSs don’t always allow developers to preview content before it’s published. The back-end editor allows content creators to input their content directly into the API, but it’s challenging to publish content without seeing how the pages behave from the user’s perspective. This leaves little room for mistakes, so developers and creators must be sure that they are making accurate changes.
基于 Git 的 CMS 与 API 驱动的 CMS
关于基于 Git 的 CMS 和 API 驱动的 CMS，没有一个比另一个更好。这完全取决于您作为开发人员的需求、您所工作的团队的才能，以及您的客户所期望的产品结果。如果你独自工作或者和一个固定的团队一起工作，做出选择会很简单。但是涉及的人员越多，就越困难。
许多组织和开发人员在时间紧张和最后期限临近时选择外包软件项目。在这种情况下，成本可能是一个重要因素。大多数自由软件开发人员要求 150-275 美元一小时的报酬，这个价格会随着经验和专业知识而上涨。有许多不同价位的基于 Git 和基于 API 的 CMS 选项，因此您一定会找到一个符合您预算的选项。
然而，考虑你的内容是在两个选项之间做出决定的最好方法。这些无头 CMS 类型之间的主要区别在于内容的存储和使用方式。在决定哪种解决方案最适合您时，这是一个至关重要的驱动力。
如何选择
切换到无头 CMS 意味着在基于 Git 的解决方案和 API 驱动的解决方案之间做出选择。虽然每个项目都需要不同级别的定制，但是您的整个开发过程应该是相同的。如果您仍然试图决定哪个选项适合您和您的团队，请确保您有一个可靠的开发策略，该策略足够灵活以适应独特的项目需求，但又足够严格以提供 CI/CD 过程的结构。
扪心自问，我的技术水平如何？我的团队能有效地使用 API 工具吗？客户期望迭代多快？你最常用的存储库是什么？你的团队对各种编码语言的理解程度如何？现在再来看看这两种无头 CMS 选项的优缺点、好处和挑战。在您最终决定之前，在采用基于 Git 或 API 驱动的解决方案之前，请确保您理解了工具背后的技术。
However, considering your content is the best way to decide between the two options. The main difference between these headless CMS types is how content is stored and consumed. This is a crucial driving force when deciding which solution is best for you.
How to Choose
Switching to a headless CMS means making a choice between Git-based and API-driven solutions. While each project will require a different level of customization, your overall development process should stay the same. If you’re still trying to decide which option is right for you and your teams, make sure that you have a solid development strategy in place that is flexible enough to accommodate unique project requirements but rigid enough to provide structure for CI/CD processes.
Ask yourself, what is my skill level? Can my teams efficiently use API tools? How quickly do clients expect iterations? What repositories do you use the most? How well does your team understand various coding languages? Now take a second look at the pros, cons, benefits, and challenges of these two headless CMS options. And before you finally settle, be sure that you understand the tech behind the tools before landing on either a Git-based or API-driven solution.
如何修改 Git 提交消息| Git 问题的解决方案
原文：https://www.gitkraken.com/learn/git/problems/git-commit-amend
我们都可以理解这种情况:您刚刚提交了更改，却发现在 Git commit 消息中拼错了一些内容。或者，您可能需要对另一个文件进行更改，该文件确实应该是提交的一部分。
当然，你可以让那句“teh”滑过去，或者只是用你忽略的改变再提交一次，但是来吧，你可以做得更好！幸运的是，Git 为如何撤销 Git 提交提供了几个选项，包括如何恢复提交，但是我们将先使用 GitKraken Git GUI，然后使用命令行来演练如何修改 Git 提交。
使用 GitKraken
修改您的最后一次提交和编辑提交消息既快速又简单
如何在 GitKraken 中修改提交消息？
使用 GitKraken 编辑您最近提交的消息非常简单。从中央图形中选择一个提交后，只需单击右侧提交面板顶部的消息开始编辑，然后单击Update message保存您的更改。
你如何修改你在 GitKraken 的最后一次犯下的错误？
在 GitKraken 中向最后一次提交添加新的更改的过程非常简单。不需要记住或运行任何命令。
暂存更改后，选中提交消息旁边的Amend旁边的框，然后单击Amend Previous Commit。在提交更改之前，您还可以在这里轻松编辑 Git 提交消息。
如何在命令行中修改 Git 提交？
是一个 Git 命令，专门用来保持语法的完整性和库的整洁。它将允许您编辑 Git 提交消息或更改您上次提交的内容。
如何在命令行中修改 Git 提交消息？
以下方法将使用更新的消息创建一个新的提交，替换以前的提交。要在命令行中更改 Git 提交消息，您将运行以下命令:
git commit --amend -m “new commit message”
在 GitKraken 中，您可以简单地从中央图中选择一个提交来查看相关的提交消息，而在终端中，您的可见性要低得多。如果您想在 CLI 中编辑之前看到 Git commit 消息，您可以去掉-m标志，只需键入:git commit --amend。
但是请记住，使用这种方法需要在 VIM 中编辑提交消息，所以您需要键入i进入INSERT模式来更改消息，然后键入esc退出INSERT模式，然后键入:wq来保存您的更改并退出。
与 GitKraken 相比，在 CLI 中编辑 Git commit 消息至少需要四个额外的步骤。但是，嘿，谁在数呢。😉
如何在命令行中修改你的最后一次提交？
要将提交修改为仅包括 CLI 中的新更改，您首先需要将工作目录中的任何更改转移到新提交中。
要修改 Git 提交以包含新的更改而不更新提交消息，您将运行:
git commit --amend --no-edit
如果您想更改上次提交的内容并编辑 Git 提交消息，您可以传入-m标志而不是--no-edit。
git commit --amend -m “new commit message”
借助适用于 Windows、Mac 和 Linux 的跨平台 GitKraken Git client ,为您的工作流程增加更多灵活性并修改 Git 提交，无论您是编辑 Git 提交消息还是修改上次提交。
如何编写一个好的 Git 提交消息| Git 最佳实践
原文：https://www.gitkraken.com/learn/git/best-practices/git-commit-message
在我们进入编写顶层 Git 提交消息的最佳实践之前，让我们先快速回顾一下 Git 中的提交是什么。
Git 提交是一种“记录对存储库的变更”的方式一个 Git 库是在。项目的 git 文件夹。简单地说，提交是本地存储库的快照。
将提交视为项目的检查点或保存点可能会有所帮助。在许多视频游戏中，在完成特定的动作或挑战后，会到达检查点并保存您的进度。类似地，Git 提交通常是在对项目做出重大贡献之后执行的，并且您希望保存您的进度。
从这个角度来看，很容易理解为什么“git commit”是最常用的 Git 命令之一。每次开发人员执行提交时，他们都可以选择编写所谓的提交消息。Git 提交消息用于解释提交的功能。
什么是好的承诺
如果通过快速查看以前的提交消息，您可以辨别每个提交做了什么以及为什么做出更改，那么您就在正确的轨道上。但是，如果您的提交消息令人困惑或杂乱无章，那么您可以通过这篇文章的帮助来改进您的提交消息实践，从而帮助您未来的自己和您的团队。 ****
例如，如果您在对项目的自述文件进行简单更新后提交，您可能会包含类似于以下内容的消息:“更新自述文件的标点符号”。现在想象一个 README 文件更新，包含以下任何提交消息:“更新标点符号”、“进行了修复”或“Chipotle 规则”。很容易看出这种类型的提交消息是如何失去控制的。虽然您可能会得到一两个跑题或不清楚的提交信息，但当它们开始累积后，很快就会回来困扰您和您的团队。在本文中，我们将介绍如何使用 GitKraken 客户端的 CLI 和 GUI 编写良好的 Git 提交消息，以及您可以应用于提交消息的提示和技巧，以改善团队沟通和存储库健康。尽管我们将引用的例子是在 GitKraken 客户端中，但是这些提示同样适用于 VS 代码用户。
例如，如果您在对项目的自述文件进行简单更新后提交，您可能会包含类似于以下内容的消息:“更新自述文件的标点符号”。现在想象一个 README 文件更新，包含以下任何提交消息:“更新标点符号”、“进行了修复”或“Chipotle 规则”。很容易看出这种类型的提交消息是如何失去控制的。虽然您可能会得到一两个跑题或不清楚的提交信息，但当它们开始累积后，很快就会回来困扰您和您的团队。在本文中，我们将介绍如何使用 GitKraken 客户端的 CLI 和 GUI 编写良好的 Git 提交消息，以及您可以应用于提交消息的提示和技巧，以改善团队沟通和存储库健康。尽管我们将引用的例子是在 GitKraken 客户端中，但是这些提示同样适用于 VS 代码用户。
GitKraken 客户端的提交图，在 CLI 和 GUI 中都可用，可以很容易地可视化引用您的提交和相关消息。
Git 提交工作流
在开始编写一流的提交消息之前，首先需要理解与 Git 提交相关的工作流。为了进行提交，开发人员必须:
更改
阶段变化
- 提交更改
- 进行更改包括添加、删除或更改本地分支上的任何内容。该分支上的任何更改都包含在所谓的工作目录中。
- 暂存更改意味着获取您已经更改的文件，并将它们移动到“准备提交”状态，称为暂存目录。您可能还会听到开发人员将临时目录称为临时区域或索引。您可以存放任意数量的文件，但请注意，多个文件存放在一起将共享相同的提交消息，这一点很重要。
这意味着您将希望确保所有的提交都以对您和您的团队有意义的方式相互关联。例如，可行的做法是，将一组文件集中在您正在处理的特定修补程序上。相反，如果每个文件关注于项目的完全不同的范围，那么存放多个文件是没有意义的。
正如我们所介绍的，提交是创建本地存储库快照的行为。这是开发人员保存工作的方式，也是一个常见的 Git 命令。
提交历史记录
一个项目中包含的所有提交的记录被称为提交历史，可以根据您使用的 Git 工具以多种方式访问。使用 GitKraken 客户端访问提交历史可以通过在内置 CLI 中运行git log来完成，或者通过简单地查看 GUI 的中央提交图来完成。
如果您使用 VS 代码，您可以利用 GitLens 在每一行代码上公开项目的提交历史，如下所示。快速识别与一行代码相关的提交消息以及作者信息的能力非常有价值。编写好的提交消息，清楚地解释代码做了什么，使得这个功能更加有用。
提交历史记录
使用 GitLens for VS Code 访问每一行代码中有价值的信息，包括作者信息、提交消息、差异视图等！
如果您使用 VS 代码，您可以利用 GitLens 在每一行代码上公开项目的提交历史，如下所示。快速识别与一行代码相关的提交消息以及作者信息的能力非常有价值。编写好的提交消息，清楚地解释代码做了什么，使得这个功能更加有用。
一个项目的提交历史对于你将来是有价值的，对于任何其他贡献代码的开发人员也是有价值的，因为它提供了关于项目中已经完成了什么的上下文。随着开发人员变得忙碌，已建立的项目文档往往会落后并变得陈旧。当这种情况发生时，许多开发人员转向提交历史来了解项目并识别最近的更新。有鉴于此，编写有意义且易于理解的提交消息变得更加重要。
Git 提交消息结构
Git 提交消息有两个主要组成部分:标题或摘要，以及描述。提交消息标题限于 72 个字符，描述没有字符限制。虽然这是既定的字符限制，但大多数开发人员建议提交消息摘要不要超过 50 个字符，描述不要超过 72 个字符。
最终，构造异常提交消息的技巧是在简洁和细节之间找到适当的平衡。简洁到易于阅读，但详细到易于理解。
一个项目的提交历史对于你将来是有价值的，对于任何其他贡献代码的开发人员也是有价值的，因为它提供了关于项目中已经完成了什么的上下文。随着开发人员变得忙碌，已建立的项目文档往往会落后并变得陈旧。当这种情况发生时，许多开发人员转向提交历史来了解项目并识别最近的更新。有鉴于此，编写有意义且易于理解的提交消息变得更加重要。
标准化 Git 提交消息结构
编写提交消息时，一致性是关键。无论您是独自工作还是与数百名贡献者合作开发一个开源项目，保持一致的风格并遵守既定的提交消息约定都是至关重要的。
建立标准化的提交消息结构有助于保持您的存储库干净、清晰，并使项目参与者更容易理解每个提交背后的目的。
如果您在团队中工作，项目负责人应该传达预期的提交消息指南。大多数开源项目在其文档中都有关于提交消息最佳实践的说明。如果您找不到清晰的文档，您可以查看提交历史，并根据过去的提交对您的消息进行建模。
诚然，遵循一个标准化的提交消息有时会令人感到乏味，但是现在花时间构建一个深思熟虑的消息不仅会在代码审查或项目审计期间节省你的时间，这是一个将你与你的同行区分开来的简单方法，并且受到项目经理的赞赏。
ProTip:一些团队在他们的提交消息摘要中包含一个类似于*的特殊字符，以表示在提交消息描述中写入了更多信息。
编写提交消息时，一致性是关键。无论您是独自工作还是与数百名贡献者合作开发一个开源项目，保持一致的风格并遵守既定的提交消息约定都是至关重要的。
想要撰写具有个人风格的精彩提交消息吗？GitKraken 客户端允许您在提交消息中使用表情符号！😍💥🦑
快速 Git 提交消息提示
您可以做一些事情来立即改进 Git 提交消息:
避免不必要的大写
仔细检查你的拼写
不要用标点符号结束提交消息摘要
不要用标点符号结束提交消息摘要
遵循这些简单的指导方针可以更容易地搜索和过滤提交，并使您的存储库看起来更具视觉吸引力。这些步骤不仅快速简单，而且你的团队成员也会感谢你。
您可以做一些事情来立即改进 Git 提交消息:
使用祈使句动词形式
- 帮助您编写好的 Git 提交消息的另一个最佳实践是使用命令动词形式。使用命令式动词形式可以确保提交消息中使用的潜在动词，如“fixed”或“updated ”,以正确的时态写成“fix”和“updated”。
- 这已经成为许多 Git 项目事实上的标准。确保您的消息符合标准的一种方法是应用公式:“如果应用，我的提交将…”您可以将此应用于示例:
- 如果应用，我的提交将(插入提交消息文本)
总结:
Add new Kief-the-kraken Keanu-Kief to keif gallery
描述:
Modify menu.yml and keif-gallery.md related to ticket #12345
这已经成为许多 Git 项目事实上的标准。确保您的消息符合标准的一种方法是应用公式:“如果应用，我的提交将…”您可以将此应用于示例:
吉拉集成问题 ID 或票证编号
在提交消息中包含附加上下文的一种方法是引用相关的吉拉问题 ID。虽然这不应该作为高质量提交消息的替代，但是添加吉拉 ID 可以帮助您团队中的其他开发人员引用关于您的提交地址的附加信息。
GitKraken Client Pro 用户可以利用吉拉集成开始在他们的工作流程中使用这种做法。
要使用 GitKraken Client Pro 编写与吉拉问题相关的提交消息，请按照以下步骤操作:
从左侧面板中选择JIRA ISSUES
找到您要参考的问题
标识问题 ID
选择问题旁边的省略号并点击Copy issue link
GitKraken Client Pro 用户可以利用吉拉集成开始在他们的工作流程中使用这种做法。
要使用 GitKraken Client Pro 编写与吉拉问题相关的提交消息，请按照以下步骤操作:
提交与问题相关的更改，并编写一条 Git 提交消息，如下例所示:
- 总结:
Update electron version to enable faster speeds <closes Jira Issue #123>- 描述:
Changes the abc in order to comply with xyz. See Jira ticket #123 for further details.paste issue link``
常规提交
传统的提交消息样式是另一种提升提交消息级别的方式。传统的提交结构包括用指定的提交类型开始提交消息。提交类型包括:
Feat–特征
Fix–错误修复
Docs–对自述文件等文档的更改
Style–样式或格式改变
Perf–提高代码性能
Test–测试一项功能
Test–测试一项功能
使用传统的提交方法，项目参与者可以轻松地筛选和搜索特定的提交，如下例所示:
总结:
Docs: Fixes typo on in-from-the-depths.md
描述:
Closes ticket #54321
Git 经常提交
另一个显著提高提交消息质量和效用的简单方法是更频繁地提交。首先，提交通常是一个好主意，因为它可以确保你的工作被保存，它还可以使你的提交信息简洁明了。
比方说，你已经完成了一整天的工作，但是还没有完成。精心制作一个清晰简洁的提交消息几乎是不可能的。
另一方面，如果您经常提交，很容易写出一个简单的提交消息，如下所示，它清楚地表达了这一点，而不会占用太多时间或过于冗长。
使用传统的提交方法，项目参与者可以轻松地筛选和搜索特定的提交，如下例所示:
Using the conventional commit method makes it easy for project contributors to filter and search for specific commits, as shown in the example below:
如何用命令行创建优秀的提交消息
要在 GitKraken 中使用 Git CLI 来使用您新发现的 Git commit 消息最佳实践，您首先需要从顶部工具栏中选择Terminal。
描述:
Closes ticket #54321
现在，您需要从您的工作目录转移变更。运行git status是查看需要暂存的文件的好方法。从这里，您有两个选择:您可以使用git add <file name>暂存单个文件，这是通常推荐的，或者，您可以使用git add -all暂存工作目录中的所有文件。
另一个显著提高提交消息质量和效用的简单方法是更频繁地提交。首先，提交通常是一个好主意，因为它可以确保你的工作被保存，它还可以使你的提交信息简洁明了。
在 GitKraken 客户端中使用 CLI 的一个惊人优势是，您不必再次运行git status来确认您的文件是否被正确暂存。
GitKraken 客户端通过其著名的提交图和有用的提交面板，可以很容易地从视觉上确认预期的 Git 操作是否真正发生。提交图显示了项目的提交历史，而右侧的提交面板显示了文件从工作目录移动到暂存目录，最后到达提交消息的过程。
从这里开始，您可以通过使用git commit -m <Summary>或更详细的git commit -m <Summary> -m <Description>来应用您所学到的 Git 提交消息最佳实践。决定使用哪一个将取决于您的团队同意的标准化提交消息机制，或者项目的默认消息结构。
请记住，现在编写一个全面而详细的提交消息将在将来为您节省时间。
如何用命令行创建优秀的提交消息
如何使用 GitKraken 客户端编写一个好的提交消息
使用 GitKraken 客户端中的 GUI 编写提交消息很简单。首先从您的工作目录中暂存您想要提交的文件。您会注意到 GitKraken 客户端在 UI 右侧的“提交面板”中保存了一个工作目录中所有未暂存文件的列表。
如果您已经对工作目录中的多个文件进行了更改，但想要暂存一个特定的文件，请将鼠标悬停在文件名上，然后单击出现在文件名右侧的Stage File按钮。要准备您的所有更改，只需选择面板右上角的Stage all changes按钮。
当文件从提交面板的Unstaged Files部分向下移动到正下方的Staged Files部分时，您可以使用 GitKraken Client 轻松验证文件是否已暂存。
从这里开始，您可以通过使用git commit -m <Summary>或更详细的git commit -m <Summary> -m <Description>来应用您所学到的 Git 提交消息最佳实践。决定使用哪一个将取决于您的团队同意的标准化提交消息机制，或者项目的默认消息结构。
一旦您的文件被暂存，您就可以编写顶层提交消息了。导航到提交面板底部标记为Commit Message的部分，并选择Summary。
这里，您有 72 个字符来总结您提交的目的，并应用本文中介绍的最佳实践。当您对提交摘要感到满意时，您可以选择下面的Description来提供额外的上下文。遵循您的团队或项目负责人制定的准则来填写详细描述。
当您对提交消息感到满意时，选择绿色的Commit changes to (#) file按钮。您可以通过参考中央提交图来验证您的提交是否成功。
使用 GitKraken 客户端中的 GUI 编写提交消息很简单。首先从您的工作目录中暂存您想要提交的文件。您会注意到 GitKraken 客户端在 UI 右侧的“提交面板”中保存了一个工作目录中所有未暂存文件的列表。
Composing commit messages is simple using the GUI in GitKraken Client. Start by staging the files from your working directory that you want to commit. You’ll notice that GitKraken Client keeps a list of all the unstaged files in your working directory in the “Commit Panel” located on the right side of the UI.
如何编辑 Git 提交消息
因为提交在 Git 工作流中非常常见，所以几乎可以肯定的是，在某些时候，您需要知道如何编辑 Git 提交消息。要求您更改 Git 提交消息的最常见原因包括打字错误和添加澄清内容。
要在 GitKraken 客户端中编辑提交消息，只需选择提交，浏览提交面板，单击显示当前提交消息的框，进行必要的编辑，然后选择绿色的Update Message按钮。就这么简单！
要在命令行中更改提交消息，可以使用:
git commit --amend -m “new commit message”
这里，您有 72 个字符来总结您提交的目的，并应用本文中介绍的最佳实践。当您对提交摘要感到满意时，您可以选择下面的Description来提供额外的上下文。遵循您的团队或项目负责人制定的准则来填写详细描述。
您应该知道，您只能编辑最近的提交。这就是为什么确保仔细检查每个提交消息的拼写和格式如此重要。
更改与旧提交相关联的 Git 提交消息需要您恢复 Git 提交，，这是一个更加核心的选项。
因为提交在 Git 工作流中非常常见，所以几乎可以肯定的是，在某些时候，您需要知道如何编辑 Git 提交消息。要求您更改 Git 提交消息的最常见原因包括打字错误和添加澄清内容。
想要帮助您的团队实现更好的沟通和可见性吗？查看 GitKraken 客户端的团队功能，包括查看团队成员正在处理的文件、深度链接、预防性合并冲突工具和灵活的许可管理。
高质量 Git 提交消息=以后节省时间
应用这些 Git 提交消息最佳实践将有助于提高您浏览项目历史、理解变更的能力，并为项目的未来提供有用的指导。编写全面的提交消息不一定是乏味的或者不合理的耗时。另外，像 GitLens 和 GitKraken Client 这样的工具可以帮助你以直观和不引人注目的方式获得编写高质量提交消息的好处！
git commit --amend -m “new commit message”
git commit --amend -m “new commit message”
您应该知道，您只能编辑最近的提交。这就是为什么确保仔细检查每个提交消息的拼写和格式如此重要。
更改与旧提交相关联的 Git 提交消息需要您恢复 Git 提交，，这是一个更加核心的选项。
Changing the Git commit message associated with an older commit requires you to revert a Git commit, and is a much more nuclear option.
想要帮助您的团队实现更好的沟通和可见性吗？查看 GitKraken 客户端的团队功能，包括查看团队成员正在处理的文件、深度链接、预防性合并冲突工具和灵活的许可管理。
Want to help facilitate even better communication and visibility for your team? Check out GitKraken Client’s team features including the ability to see which files your team members are working on, deep linking, preventative merge conflict tool, and flexible license management.
高质量 Git 提交消息=以后节省时间
应用这些 Git 提交消息最佳实践将有助于提高您浏览项目历史、理解变更的能力，并为项目的未来提供有用的指导。编写全面的提交消息不一定是乏味的或者不合理的耗时。另外，像 GitLens 和 GitKraken Client 这样的工具可以帮助你以直观和不引人注目的方式获得编写高质量提交消息的好处！
Applying these Git commit message best practices will help improve your ability to navigate your project’s history, understand changes, and provide useful direction for the future of your project. Writing comprehensive commit messages doesn’t have to be tedious or unreasonably time consuming. Plus, tools like GitLens and GitKraken Client are here to help you capture the benefits of writing high-quality commit messages in intuitive and unobtrusive ways!
7 个(致命的)常见 Git 错误以及如何修复它们
Git 是一个版本控制系统，被世界上绝大多数开发人员使用。Git 是由 Linux 大师 Linus Torvalds 开发的，自 2005 年以来已经对公众开放，并使开发人员的生活变得更加容易。
有了 Git，团队工作和文件协作变得更加容易，它有助于更快地开发软件产品。不再强制团队中的每个程序员处理不同的文件；他们可以在同一时间处理相同的文件，最终， Git 合并他们的更改而不影响其他人。Git 帮助开发人员跟踪他们代码库的版本，并有效地与不同的团队成员协作，以实现软件产品的无错误交付。
当然，在这些情况下协作， Git 合并冲突可能会发生。使用健壮的 Git 工具，像 GitKraken 客户端，可以把你团队的 Git 工作流程带到下一个层次。当两个团队成员同时处理同一个文件时，预测性合并冲突警报等功能会通知您，以便您可以在冲突发生之前先发制人地避免冲突。
虽然 Git 很常见，但它有许多功能——不仅仅是准备、提交和推送对远程 Git 库的更改。Git 实际上非常强大，但是许多开发人员不知道如何利用它提供的所有特性。
很多人害怕在 Git 中犯错误，因为他们没有很好地理解它。每天，开发人员都会对代码库进行大量的修改，因此很难跟踪每一个修改并有效地提交它们。
同时处理多项任务也很容易出错。如果您是一名在 Git 中犯常见错误的开发人员，本文将教您如何不惊慌地修复它们。另一方面，如果你是一名工程经理，想要雇佣远程开发人员，这是与你的团队分享的一个很好的资源，这样他们就能理解这些错误和解决方案。
1.意外删除文件
在 Git 中意外删除文件是很常见的错误。例如，在进行功能升级时，开发人员通常认为有些文件是不需要的，在这种预期下，他们会在文件的需求到期之前将其删除。
如果您不小心删除了 Git 中的一个文件，您可能会认为自己犯了一个不可挽回的错误。但是不用担心；Git 对文件非常慷慨。它总是跟踪存储库中添加或删除的文件。这意味着您只需一个 Git 命令就可以取回您的文件。或者，你可以使用 GitKraken 客户端中神奇的撤销按钮。
“@GitKraken 刚刚在一次丢弃所有后救了我。”–@ QiMata
如果您不小心删除了 Git 中的一个文件，您可能会认为自己犯了一个不可挽回的错误。但是不用担心；Git 对文件非常慷慨。它总是跟踪存储库中添加或删除的文件。这意味着您只需一个 Git 命令就可以取回您的文件。或者，你可以使用 GitKraken 客户端中神奇的撤销按钮。
为了更好地理解，我们假设，例如，您已经从 Git 存储库中删除了 404.html 文件。要取回文件，您可以在您选择的终端中键入以下命令。
git checkout HEAD 404.html
一旦您运行了上面的 Git checkout 命令，您将获得您的存储库的 404.html 文件的最新提交版本。如果您使用 Git status 命令检查存储库的状态，您将看到 404.html 不再位于 deleted files 下。现在可以在代码编辑器中对其进行修改。
GitKraken 客户端为用户提供了一个 CLI 和 GUI，因此开发者可以为他们的工作流程选择最好的工具。不再需要手动检查您的回购状态；GitKraken 客户端的图形会随着操作的完成而自动更新，因此您可以立即确认事情是否按预期运行。
2.推送未完成的代码
作为一名开发人员，您经常会最终致力于需要极快交付的重要功能，或者困扰用户并需要快速解决的生产 bug。在这种高压力的情况下，您可能会忘记切换您的工作 Git 分支，并最终将文件提交到主分支。
将未完成的代码推送到远程主分支可能会对团队工作流的 CI/CD 和部署部分造成严重破坏。
如果您最近将您的代码推送到一个远程主分支，如果您将远程分支的先前版本与您的本地分支同步，您可以恢复这些更改。您可以使用下面的命令获取远程分支的旧版本。
git reset - -hard <remote_branch>/<branch>@{1}
在这个上下文中使用的 Git reset 命令将使用主分支的本地历史的最后工作版本来重置和更新您的远程分支。如果您想保护这个分支免受这样的直接提交，您也可以在您的远程 Git 存储库中使用下面的设置，并将其与本地同步。
git config --system receive.denyNonFastForwards true
3.可怜的 Git 提交消息
编写好的提交消息对于拥有一个每个人都能理解的更好的代码库是必不可少的。提交消息对于任何查看代码的人来说都是不言自明的。诸如“已修复”、“已编辑”等消息。，没有任何附加的上下文就没有任何作用。
许多开发人员在快速工作时犯了添加糟糕的提交消息的错误，最终，他们希望他们已经编写了更好的提交消息，不仅仅是为了他们的团队成员，也是为了他们自己。
好消息是 Git 允许您随时编辑提交消息。要编辑提交消息，使用下面的 Git commit amend 命令:
git commit --amend
在终端中键入上述命令后，按 enter 键。这将打开一个文本编辑器，您可以在其中轻松编辑最后一条提交消息。
4.意外删除整个 Git 分支
在一个分支上工作很长时间，最后，在没有合并的情况下不小心删除了它，这听起来是开发人员最大的恐惧。但这并不像人们想象的那么重要。您只需从终端发出几个命令就可以恢复该分支。
为了完美地恢复分支，首先需要找到切换到被删除分支的提交。为此，可以使用 Git reflog 命令
获取提交和详细信息的所有日志条目。一旦您找到了提交，您可以使用下面的命令来恢复您删除的分支，这样您就可以合并并将其推送到远程分支。
git checkout -b <branch-name> <commit-id>
在上面的命令中，branch-name是您删除的分支名称，commit-id是您从 Git reflog 结果中确定的提交。
5.错误的 Git 提交
提交时出错是一个常见的 Git 错误，但也可能是毁灭性的。例如，您的提交可能会给您的代码库带来问题，或者与另一个变更发生冲突。
如果错误通过了部署阶段，这些错误会对生产构建造成不可估量的损害。但是如果你及早发现错误，你可以采取措施来补救。
通过使用下面的 Git revert commit 命令恢复到旧的提交来修复错误的提交:
git revert <commit-id>
在上面的命令中，commit-id是旧提交的提交 id，它具有更好、更稳定的代码版本。
6.Git 提交太多
Git 习惯于增量地跟踪代码库中的变更，但有时人们最终会进行太多的提交。这通常发生在你尝试新事物的时候，当事情开始起作用时，你在整个过程中不断地提交。
最后，当实验成功，并且您准备好提交到主分支时，您可能会留下许多带有不太清楚的提交消息的提交。这些提交会让其他开发人员很难理解你的代码。
在这种情况下，您可以求助于从终端压缩提交，然后将您的更改推送到远程。下面是将多个提交压缩为一个的过程。
5.错误的 Git 提交
首先，使用下面的命令签出到您想要合并的分支:
git checkout <branch-name>
接下来，使用以下命令:
git merge - -squash <branch-name-to-be-merged>
一旦执行了上面的两个命令，就会有一些需要解决的合并冲突。
7.忘记添加文件了
忘记添加文件是另一个常见的 Git 错误，可能会带来麻烦。有时您可能有不同的目录，如果您忘记在提交中添加一个重要的文件，您可能会得到一个糟糕的代码库。
要快速修复这个错误，可以使用下面的 Git add 命令:
git add <missed-file>
执行上述命令后，使用:
git commit - -amend
这将把文件添加到最后一次提交。
减少常见的 Git 错误
Git 是一个强大的工具，但是你只能通过学习更多关于 Git 的知识来利用它的所有好处。没什么好害怕的。Git 很复杂，但是一旦你学会了 Git ，你就不会对错误感到恐慌，并且会对你的工作流程更有信心。
不要担心犯这些常见的 Git 错误——您可以用几个命令来修复它们。
- 首先，使用下面的命令签出到您想要合并的分支:
GitKraken 客户端帮助所有技能水平的开发人员更好地理解 Git 操作，实现更自信的工作流，减少错误。今天就升级到世界上最流行的 Git 客户端——GUI 和终端！
- 接下来，使用以下命令:
git merge - -squash <branch-name-to-be-merged>
- 一旦执行了上面的两个命令，就会有一些需要解决的合并冲突。
7.忘记添加文件了
忘记添加文件是另一个常见的 Git 错误，可能会带来麻烦。有时您可能有不同的目录，如果您忘记在提交中添加一个重要的文件，您可能会得到一个糟糕的代码库。
要快速修复这个错误，可以使用下面的 Git add 命令:
git add <missed-file>
执行上述命令后，使用:
git commit - -amend
这将把文件添加到最后一次提交。
减少常见的 Git 错误
Git 是一个强大的工具，但是你只能通过学习更多关于 Git 的知识来利用它的所有好处。没什么好害怕的。Git 很复杂，但是一旦你学会了 Git ，你就不会对错误感到恐慌，并且会对你的工作流程更有信心。
不要担心犯这些常见的 Git 错误——您可以用几个命令来修复它们。
GitKraken 客户端帮助所有技能水平的开发人员更好地理解 Git 操作，实现更自信的工作流，减少错误。今天就升级到世界上最流行的 Git 客户端——GUI 和终端！
Git is a powerful tool, but you can only leverage all of its benefits by learning more about Git. There’s nothing to fear. Git is complex, but once you’ve learned Git, you won’t panic about mistakes and will feel more confident in your workflow.
Don’t worry about making these common Git mistakes–you can fix them with a few commands.
GitKraken Client helps developers of all skill levels better understand Git actions, enabling a more confident workflow with less mistakes. Level up today with the most popular Git client in the world – with a GUI and terminal!
Git 配置|配置您的用户名和电子邮件|了解 Git
Git config 是一个强大的 Git 命令，它允许你定制 Git 的工作方式，并优化它以适应你的工作流程。如下所示，Git 从缩小的文件列表中提取配置设置。下图中的每个配置级别都可以覆盖其上一级的配置设置。例如，Git config 全局设置会覆盖 Git config 系统设置，但不会覆盖 Git config 本地设置。
在下载 Git 之后，大多数开发者会立即运行 Git config 命令来设置他们的用户名和电子邮件。之后，有成千上万种方法可以配置 Git 来适应特定的用例和工作流。
为了保持简单和信息丰富，我们将解释最常见的 Git 配置级别，包括 Git 配置系统、全局和本地，以及如何在命令行和 GitKraken 客户端中配置您的用户名和电子邮件。
目录
有了 GitKraken Client，您可以直接开始利用 Git 的强大功能，而不必下载或配置它。
Git 配置系统
Git 配置系统级别是最广泛的配置级别，包含整个计算机的配置信息。因为 Git config 系统配置是特定于计算机的操作系统的，所以大多数开发人员倾向于保留这个级别的默认配置设置。
要在终端中查看 Git 配置系统设置的完整列表，请运行:
git config –system –list
Git 配置全局
Git config 全局配置作为用户应用于您，存储在您的主目录中，并且可以覆盖 Git config 系统设置。与系统配置不同，开发人员定期定制 Git config 全局设置以适应他们的工作流。一些常见的 Git config 全局配置可用于设置您的用户名、电子邮件地址、默认编辑器、提交消息模板、终端颜色、自动更正等等。
要在终端中查看 Git 配置全局设置的完整列表，请运行:
git config –global –list
Git 本地配置
Git 配置本地级别包括特定于 Git 存储库的设置，并覆盖全局和系统级别的 Git 配置。开发人员经常使用 Git config local 命令来更新与他们的工作相关的用户名和电子邮件，这取决于他们所工作的存储库的类型。
我们将用 GitKraken 可爱的北海巨妖吉祥物 Keif 来演示这个过程。假设 Keif 的全球配置使用他们的工作邮箱: keif@kraken.sea 。这意味着 Keif 的所有 Git 提交都与 keif@kraken.sea 电子邮件相关联，除非它们运行 Git config 本地命令来更改特定 Git 存储库的相关电子邮件。
现在让我们假设 Keif 已经完成了当天的工作，现在他们想要为他们最喜欢的开源项目 GitLens 做贡献。Keif 不希望他们的工作电子邮件与他们在这个项目中的提交相关联，而是更喜欢使用他们的个人电子邮件:【steampunkkraken@cephalopod.com*。为了确保他们对 GitLens 回购的贡献与 steampunkkraken@cephalopod.com的电子邮件相关联，Keif 可以简单地运行以下命令:*
git config --local user.email steampunkkraken@cephalopod.com
现在，Keif 对 GitLens 库的贡献将与他们更喜欢的个人邮件而不是工作邮件联系在一起。请记住，有了这个过程，Keif 在返回工作时将不必运行任何 Git config 命令，因为他们只更新了 GitLens 存储库的本地配置。
要查看 Git 配置本地设置的完整列表，请运行:
git config –local –list
Git 配置本地级别包括特定于 Git 存储库的设置，并覆盖全局和系统级别的 Git 配置。开发人员经常使用 Git config local 命令来更新与他们的工作相关的用户名和电子邮件，这取决于他们所工作的存储库的类型。
命令行中的 Git 配置用户名
现在您已经对不同的 Git 配置级别有了大致的了解，让我们来看看如何使用 Git config 命令来设置您的用户名和电子邮件。Git 要求在您可以利用它的所有功能之前建立用户名和电子邮件，所以在您下载 Git 之后立即解决这个问题是一个好主意。
要使用 Git config username 设置您的用户名，请导航到终端并运行:
git config --global user.name "Your Name"
要查看 Git 配置本地设置的完整列表，请运行:
命令行中的 Git 配置电子邮件
要使用 Git config email 在终端中设置您的电子邮件，请运行:
git config --global user.email youremail@example.com
git config --global user.name "Your Name"
值得注意的是，因为使用了全局级配置，Git 将使用您为您创建的每个后续 Git 存储库设置的用户名和电子邮件，除非您执行本地配置以逐个存储库地覆盖它。
命令行中的 Git 配置电子邮件
Git 将您的默认分支名称配置为 Main
2020 年，GitHub、其他托管服务和整个开发社区合作，将默认或初始分支名称从 master 改为 main。这反映了社会意识向更具包容性的术语的转变。阅读更多关于从主到主的变化。
要将默认分支名称从 master 更改为 main，请在终端中运行以下命令:
git config --global init.defaultBranch main
现在，每当您初始化一个新的 Git 存储库时，创建的第一个分支将被称为 main。
2020 年，GitHub、其他托管服务和整个开发社区合作，将默认或初始分支名称从 master 改为 main。这反映了社会意识向更具包容性的术语的转变。阅读更多关于从主到主的变化。
在命令行中显示 Git 配置
您可以通过在终端中运行 show Git config 命令来查看所有 Git 配置设置:
Git config –list –show-origin.
终端将按照我们之前讨论过的层次顺序返回您的 Git 配置设置，从系统级开始，缩小到全局和本地。
现在，每当您初始化一个新的 Git 存储库时，创建的第一个分支将被称为 main。
Git 客户端的 git 配置
使用 GitKraken Client ，您可以开始使用 Git 及其所有功能，而无需运行任何 Git config 命令。事实上，如果你使用 GitKraken 客户端，你根本不需要在你的机器上下载 Git。为了在不运行 Git config 命令的情况下在 GitKraken 客户端自定义您的用户名和电子邮件，请遵循以下步骤:
选择右上角的齿轮图标⚙️进入您的Preferences
在左侧面板中，点击Profiles
在Profiles部分选择您姓名旁边的三个省略号，并从下拉菜单中点击Edit Profile
从这里您可以更新您的Author Name和Author Email
您可以通过更新 GitKraken 客户端Preferences左侧面板中的选项来访问进一步的定制和配置设置。
用它来配置 Git
- 我们已经介绍了 Git config 命令的基本层次，并展示了一些开发人员如何使用这个命令定制 Git 的例子。如果你想深入了解更高级的 Git 配置选项，请访问官方 Git 配置文档。随着您对 Git 越来越熟悉，您将会遇到更多独特的方式来配置它以满足您的开发需求。GitKraken 客户端支持您独特的 Git 配置，但也允许您在根本不需要配置 Git 的情况下利用 Git，从而节省您的时间和精力。免费试用 GitKraken 客户端，让你的 Git 技能更上一层楼。
- 在左侧面板中，点击
Profiles - 在
Profiles部分选择您姓名旁边的三个省略号，并从下拉菜单中点击Edit Profile - 从这里您可以更新您的
Author Name和Author Email
您可以通过更新 GitKraken 客户端Preferences左侧面板中的选项来访问进一步的定制和配置设置。
用它来配置 Git
我们已经介绍了 Git config 命令的基本层次，并展示了一些开发人员如何使用这个命令定制 Git 的例子。如果你想深入了解更高级的 Git 配置选项，请访问官方 Git 配置文档。随着您对 Git 越来越熟悉，您将会遇到更多独特的方式来配置它以满足您的开发需求。GitKraken 客户端支持您独特的 Git 配置，但也允许您在根本不需要配置 Git 的情况下利用 Git，从而节省您的时间和精力。免费试用 GitKraken 客户端，让你的 Git 技能更上一层楼。
Git Config-gy with it
We’ve covered the basic hierarchy of the Git config command and shown a few examples of how developers use this command to customize Git. If you want to delve deeper into the more advanced Git config options, visit the official Git config documentation. As you become more familiar with Git, you’ll encounter more unique ways you can configure it to fit your development needs. GitKraken Client supports your unique Git configurations, but also allows you to leverage Git without having to configure it at all, saving you time and mental energy. Try GitKraken Client for free and take your Git skills to the next level.
Git 连续交付|将自动化引入 Git
https://www.youtube.com/embed/jlNfUO-NKb8?feature=oembed
视频
软件开发很难。承认这一点是可以的。编写代码非常困难，并且伴随着很大的压力，这使它成为一个压力非常大的职业。理想情况下，您应该总是在寻找减轻软件开发生活中日常痛苦的方法。一种方法是通过自动化，这正是 CircleCI 的 Angel Rivera 在 2021 Git kon Git conference 的演讲中所涵盖的内容。
软件的目的是什么？
安吉尔对目的问题的回答是“软件的存在是为了满足最终用户的需求。”这可以通过创建数字服务和解决方案来实现，这些服务和解决方案可以提供快速、可靠、一致和安全的结果，虽然这可以采取多种形式，但最终本质上来说，软件可以实现自动化。软件有助于具体对象和物理执行过程的数字表示，例如开灯或关灯，或者在某些情况下，在线购物和支付。
开发软件有很多方法和工具。像文本编辑器、编程语言和框架这样的工具是每个开发人员至少必须拥有的构建软件的工具。但是除此之外，开发人员必须学习许多概念和方法才能成功。有很多东西要学，而且常常感觉软件开发的工作是无止境的。
但是隧道的尽头有光；开发人员可以采用一些工具、概念和实践来减少软件开发中最困难和最乏味的部分。
GitKraken Client 是为满足用户需求而发展的工具的完美范例，具有交互式拉请求管理、合并冲突检测和解决、深度链接等高级功能。
Git 和连续交货
Git 和持续交付是一对很好的组合，当它们结合在一起时会提供巨大的价值。让我们先来看看 Git 在合作关系中扮演什么角色。
Git 是一个版本化工具，使开发者能够捕捉和版本化代码变更。Git 因为占用空间小和分布式架构，很受开发者欢迎。有了 Git，可以在隔离的 Git 分支中开发变更；这有助于防止不需要的代码或错误被引入到生产中。Git 为我们提供了一种安全地试验代码的方法，并有助于减少错误。但是如果确实出错了，Git 可以很容易地将代码库恢复到安全状态。
手工 Git 开发流程和代码评审
使用 Git 的典型开发人员工作流程如下所示:
- 您 Git 将下载到他们的本地环境中。
- 您在开发环境中本地修改代码，处理特性或修复 bug。
- 当你到达一个里程碑时，你 Git 提交那些本地代码变更。
- 您将这些代码更改推送到上游分支，也许是推送到 GitHub 上的 repo。
- 其他开发人员开始手动代码审查过程。
手动代码审查过程意味着开发团队需要有人阅读和审查被提议或提交的代码变更，然后再将它们合并到产品级分支中。其他开发人员仔细检查代码，看是否有已知的 bug、错误以及是否符合编码标准。
手动代码审查是有帮助的，并且比仅仅相信如果它在本地工作，它将在生产中工作要好得多，但是手动代码审查在时间和资源方面也是非常昂贵的。由于是人在审查代码，这个过程很容易出现人为错误。
手动代码审查过程的另一个关注点是审查有问题的代码，或者甚至开始审查要花多少时间。开始审查提交的代码可能需要一个小时、一天、一周、一个月甚至更长的时间。完成审查可能需要更长的时间。如果评审人员发现任何缺陷、错误或错误，代码就会被拒绝，提交代码的开发人员必须重新开始这个循环。与此同时，项目中可能会引入其他变化，从而进一步增加复杂性。
CircleCI 估计，平均一个开发者的时间成本大约为每分钟 1.42 美元。算一算，一个普通的代码审查大约需要 120 分钟，在一些团队中，可能有 10- 20 个开发人员参与。这一切很快变得非常昂贵。
持续集成和持续交付原则
控制代码开发和评审成本意味着使代码评审过程更加高效。持续集成和持续交付(CI/CD)实践提供了一条通过自动化使任何工作流更加高效的途径。核心上，CI/CD 本质上是使用自动化工具构建、测试和交付代码和用户环境变更的实践。
CI/CD 为我们提供了可以在软件开发团队中采用和实现的原则。在 Git 的上下文中，持续交付和持续集成原则通常意味着开发人员将经常提交代码到共享的代码库中，并在每次提交时测试代码。
更快的反馈循环
CI/CD 为开发人员提供了更快的反馈回路。因为您不需要等待人工时间管理来开始评审过程，您可以在几分钟甚至几秒钟内发现您的代码是否合格。这种快速的反馈循环让你尽可能快地修复代码中的错误，最终减少代码变更到达最终用户的时间，实现软件的目标。
共享存储库
Git 在这里起着核心作用。持续集成的核心原则之一是将团队中每个开发人员的所有工作副本合并到一个共享的代码库中。Git 让开发人员可以自由地在本地工作，在不妨碍其他用户的情况下，尽可能多地试验他们需要的分支。当您的代码准备好了，Git push 就是将他们的更改集成到共享存储库中所需要的一切。
有了 GitKraken 客户端，像推和拉这样的操作只需点击一下。拖放操作可以从可视化的、易于阅读的提交图中推送和拉出更改，或者在 Git 增强的终端中使用自动完成命令。
部署自动化
持续交付和持续部署的另一部分是自动将新软件版本部署到目标环境的实践。不仅是最终用户将与代码交互的生产环境，还有测试和试运行环境。在测试环境中，可以部署测试工具来检查错误或其他问题，安全地远离其他环境。
CI/CD 的所有原则确实依赖于自动化来使它们有效。正是自动化通过定义和执行软件交付实践或过程，将这些原则转化为现实。
CI/CD 管道& CircleCI
将 CI/CD 的这些原则转化为现实的一个途径是采用和实现一个持续的交付平台，如 CircleCI ，并建立 CI/CD 管道。
管道本质上是一组需要针对代码执行的东西，以确保代码得到正确测试。当然，管道需要测试代码是否正确编译，以及工件或二进制文件是否如预期的那样输出。但是还有很多其他的东西可以测试，比如安全扫描或者吞吐量测试。无论您在软件开发评审过程中需要做什么，您都可以在 CI/CD 管道中使用 CircleCI 来实现自动化。
下图显示了 CircleCI 平台中 CI/CD 管道的视觉效果。
这是 Angel 所谓的“快乐之路”的一个例子，在自动化代码审查过程中，一切都是正确的:
- 代码从本地开发环境被推送到共享分支。
- CircleCI 检测这些变化，然后测试代码。
- 所有测试都通过了，CircleCI 中的事务和构建工作也通过了。
- 最后，变更被推送到主分支，准备在下一个发布周期中传播。
当然，并不是每条路都是幸福的。让我们看一下使用自动化的相同过程，以及当它失败时会是什么样子。
在这种失败的情况下:
代码从本地开发环境被推送到共享分支。
三项测试中有两项失败。
- 构建了 Docker 映像，但是没有部署代码。
- 一旦系统检测到故障，它就通知开发人员这个问题。
- 开发人员开始修复问题，然后再次运行整个过程。
- Once the system detects the failure, it notifies the developer of the problem.
- 自动化程度更高，手动问题更少
手工过程存在于每个开发周期中，但是有很多你可以并且应该自动化的。减少代码评审过程中所涉及的人力资源是一种有助于加速发布周期时间和增加代码可靠性的方法。CI/CD 还意味着更快的反馈循环，因为测试和审查代码在每次提交和推送时都会自动进行。
另一个好处，也许不太明显，是 CI/CD 改善了围绕代码的整体协作，导致更好的团队协同。当团队能够在危险信号实际发生之前阻止或捕捉到危险信号时，他们会更有凝聚力。更少的错误意味着更顺畅的工作场景和更高的士气。
例如，让我们想象这样一种情况，两个不同的开发人员接触存储库中的相同文件。在他们开始编写代码之前，他们可以合作决定谁先编写代码的顺序，这有助于避免经常发生的 Git 合并冲突。从开发人员的盘子里拿走手动代码审查的时间，对于确保他们有足够的时间来有效地合作和计划有很大的帮助。
Another benefit, perhaps less obvious, is that CI/CD improves overall collaboration around code, leading to better team synergy. Teams function more cohesively when they can stop or catch red flags before they actually happen. Fewer errors mean smoother working scenarios and higher morale.
合适的工具和自动化 FTW！
点击此处，观看 Angel 在 CircleCI 中实现 CI/CD 管道的演示，自动化大部分代码审查过程。
无论你最终如何实施持续交付战略，它都始于与你的团队一致而清晰的沟通。GitKraken 客户端的团队功能可以帮助你深入了解你的团队是如何协作的。除此之外，g it 的使用变得更加简单和安全，同时 Git 的高级工作流使任何规模的团队的开发人员都可以使用。立即开始缩短部署和发布周期，并下载 GitKraken 客户端！
The Right Tools and Automation FTW!
Click here to see Angel walk through a demo of implementing a CI/CD pipeline in CircleCI, automating much of the code review process.
No matter how you finally implement a continuous delivery strategy, it starts with consistent and clear communication with your team. The team features of GitKraken Client can help you get betting insight into how your team is collaborating. And that’s on top of making it much easier and safer to use Git, while unlocking the advanced workflows Git enables developers on teams of any size. Start down the path of reduced deployment and release cycle times today and download GitKraken Client!
扫一扫
4527
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
