如何告诉Git更改是短暂的，不应该提交？

Question

当维护一个生产系统时，我发现有时需要对文件进行即席临时更改 - 改变日志级别，在脚本中添加跟踪选项等。

在我这样做的时候，我的半自动化机制会经常出现误报：

• 如果我将更改保持未提交状态或者只是暂存状态，那么我的检测脚本就会将代码库标记为脏。
• 如果我将它们作为“临时更改提交”提交，则它们被标记为“超前于远程分支的更改”
• 如果我将它们提交到一个没有远程的新分支上，则它们被标记为“没有远程的分支”。

通常，所有这些都是需要找到尚未合并的更改，但这也意味着所有“隐藏”临时更改的方法也被封锁了。

请注意，我不想使用 --assume-unchanged，因为同一个文件通常会包含既有临时更改（我不想被提醒），也有永久更改（我想要），而查看Git中处理临时更改（不要提交）没有提供适合我所有需求的建议。

使用Mercurial时，我会研究如何使用 Mercurial Queues 来接近我想要的结果。我会创建一个包含我的临时更改的补丁，然后如果我的分析工具找到了一个补丁队列，它就会弹出它们，执行分析，然后再将它们推回去。这将有效地删除仅限于临时更改的部分，仅对我未认为是临时的更改进行分析，然后重新应用那些更改。

任何改变工作目录的方法都会影响生产系统的行为 - 例如，我们的日志记录系统每隔10秒钟检查一次日志配置更新。

那么，我怎样才能最好地向Git表明某些更改是短暂的，不应该被提交和/或合并，而其他更改则应该呢？

- Mark Booth

---

如何更改代码以使所有更改都在未版本化的配置文件中进行？ - choroba

我对这个用例感到困惑 - 你说你正在对一个活跃的系统进行更改，但同时又表明在本地提交会导致检查程序出现问题，因为该分支不是远程分支。你能详细说明一下这个本地仓库、任何活动服务和远程之间的关系吗？比如，本地相对于远程的功能是什么等等。 - LightCC

我不确定你在问什么，@LightCC。本地实时存储库包含实时系统的源代码、实际运行服务的已编译代码（被gitignore忽略）和配置（spring，可能会暂时更改）。这是你想要的信息吗？检查器专门查找未提交的更改、未推送到远程的提交和没有远程的分支（因此暗示它们还没有被推送），因为这些都是我通常想知道的事情，除非这些更改是暂时的-因此我的问题。 - Mark Booth

如果我理解正确的话，远程库是中央仓库（是指Github、Github企业版等吗？），而本地库是现场服务器，你可以从远程库拉下其他开发人员做出的更改。同时，你也会在现场服务器上进行更改（听起来很危险），包括本地和暂时的优化，有时你想要推回去，有时则不需要。这个描述合理吗？ - LightCC

还有，仍然不清楚 - 您肯定想要将临时更改保存在存储库中，而不仅仅是本地配置文件吗？ - LightCC

是的，工作目录中的一些更改可能是临时的，而其他更改则需要提交和推送。理想情况下，临时更改应仅在工作目录中，我不介意它们存在于本地存储库中，只要它们永远不会传到远程。 - Mark Booth

Answer 1

对于这些文件，您可以设置一个清理脚本，负责将它们恢复为最初检出时的原始内容。
该脚本可以简单地执行git checkout -- afile，以将其内容恢复到HEAD（丢弃任何本地更改）。

通过内容过滤器驱动程序，使用.gitattributes声明自动化执行该脚本来还原文件。 ^{（图片来源："自定义Git-Git属性"，来自Pro Git书）} 一旦你在本地的 git 配置中声明了内容过滤器驱动程序，它就会在 `git commit` 时自动还原文件。
或者在 `git diff` / `git status` 中将文件视为未更改。
请参阅 "最佳实践-Git+构建自动化-保持配置分离" 中的完整示例。

- VonC

---

目前我不清楚这会如何有所帮助，但我会进行调查并可能更新我的问题。 - Mark Booth

@MarkBooth 它怎么可能不会有帮助呢？所有你本地的修改都将被忽略，正如所请求的那样。 - VonC

就文件而言，我认为无法在块级别上实现。我希望将某些文件更改标记为“不重要”，因此不会触发任何警告，而所有其他更改都会发出警告。如果我使用Mercurial进行此操作，我将使用Mercurial Queues将不重要的更改放入补丁中，在分析之前弹出它，并在之后将其推回。我将编辑我的问题。 - Mark Booth

可以在代码块级别上实现。但是你需要编写脚本。 - VonC

Answer 2

同一个文件通常会包含临时更改（我不想被提醒）和永久更改（我想要的）。如果我将[临时更改]作为“临时更改提交”提交，它们会被标记为“超前于远程分支的更改”。如果我在没有远程的新分支上提交它们，则它们会被标记为“没有远程的分支”。

如果我使用Mercurial进行此操作，我将使用Mercurial Queues将不重要的更改放入补丁中，并在分析之前弹出它，之后再推回去。

Git是你的仆人。您决定提交的含义。提交您的更改并使用Git来分发hunks，以便它们具有最有用的提交序列和边界。将不重要的更改保留在“不重要的更改”提交中，或者拥有一个“不重要的更改”分支，或者任何最好的方法。教你的检查器识别不重要更改的提交。

从您所提供的内容来看，一个普通的“本地”分支，其中包含一个专门用于配置更改的提示提交，应该就可以了。当您进行“重要”更改时，请提交并使用交互式或自动压缩重写记录更改在提示后面。告诉您的检查器忽略本地分支提示中的任何内容；要更新本地配置，请更改并使用git commit --amend --no-edit进行提交，或者如果您犯了错误并单独提交了它，则使用交互式重写压缩它或等效地只需git reset --soft @~并执行您想要执行的--amend --no-edit提交。没有特殊设施的必要，您可以获得适用于任何工作的完整工具包。如果有被认为特别有意义的提交，请将它们放在保留具有该特定含义的提交的某个地方。

- jthill

---

嗯，我在想编写一个 git-rot 是否会很容易，它可以将无关紧要的更改提交到最顶端，并将重要的更改提交推到它们的后面。这可能会使工作流程更加简单。我会仔细考虑这个问题。 - Mark Booth

{btsdaf} - jthill

{btsdaf} - Mark Booth

{btsdaf} - Mark Booth

Answer 3

凭借你的最终目标/用例，在黑暗中试图猜测你能/愿意在你的系统或半自动化的“仓库健康”系统中改变什么。这取决于你能够/愿意在哪个系统中进行更改。

1. 修改系统，使您需要更改的配置项具有“主/默认”配置文件和未跟踪的本地/用户配置文件。用户配置中的任何设置都将覆盖默认设置。

   • 优点：您可以更新“存储库健康状况”脚本，警告您存在临时设置（无需采取措施），不管是一直或是在一定时间之后等等。
   • 优点：Git 本身不需要执行任何操作。
   • 缺点：无法跟踪这些设置随时间的变化。

2. 使用特殊的分支名称/扩展名或使用特殊的标签来捕获临时设置提交，并更新您的“存储库健康状况”脚本以忽略那些分支/标签（或者警告您而非强制执行某些操作？）。

   • 示例- 使用某些特殊命名约定（始终以“tempsetting-”开头，以“.tmp”结尾等），对捕获这些内容的分支进行命名，或使用 tmp 分支进行提交，然后标记它们（可能再次采用某些特殊的命名约定）。
   • 优点：如有需要，则可以在存储库中捕获您的临时设置。
   • 缺点：这里需要做更多的事情-需要积极管理的不仅仅是配置文件或用户设置等。

- LightCC

---

我曾考虑在提交消息中使用前缀或后缀，并修改工具以考虑该问题，但感觉很混乱，我希望有更好的解决方案。我们已经有一个非正式协议，即可以在提交消息中添加“DO NOT MERGE”，人们不会执行拉取请求或提交gerrit更改。 - Mark Booth

我认为标签可能是更好的选择。因此，您可以使用tmp或其他分支进行侧面提交，然后使用特殊格式的标签进行标记。然后，您可以删除tmp分支并仅保留标签。我可能需要对一些细节进行一些研究，但这似乎是最符合Git流程的最佳方法，同时还可以避免只有不同提交消息特定前缀/后缀等的缺点。即很容易知道哪些提交是这些特殊提交，等等。应该更新答案以使其更清晰。 - LightCC