git是否以原子方式写入文件

我在文档中找不到任何东西。 如果我进行git拉取，是否可以保证合并后的底层文件是原子编写的

关于我试图实现的目标的更多背景： 我有一些定期执行git拉取的脚本，我需要知道在拉取期间是否可以依赖文件的有效状态

我们基本上使用git作为部署工具。我们从来没有通过设计来合并冲突。在远程端，一个作业每x秒持续拉动一次，其他作业读取文件。可能发生的情况是，我们在git提取文件时打开了一个文件，而文件的内容并不是我们所期望的。 除非git足够聪明，能够在底层OS RedHat上使用一些原子交换，否则这是不可能的。在这种情况下，简单的答案是否定的

值得考虑的是，git pull根本不是关于文件，而是关于提交。文件只是一个副作用。：-pull操作只是git-fetch-get-committes，然后是第二个git命令，通常是git-merge。合并步骤合并提交。如果操作不是快进而不是合并，则合并文件也会产生副作用；然后，当合并或快进完成时，Git对结果提交进行Git签出

所以这可以归结为：git签出在操作系统级别是原子的吗？答案是非常响亮的“不”：它在任何方面都不是原子的。在工作树中写入的单个文件使用操作系统级别的写入调用一次写入一个，而这些写入调用不是原子级的。需要创建或删除的文件一次只创建一个。Git确实使用索引，即在工作树上保留选项卡，以尽量减少删除、创建或重写的文件数量。Git还针对其他Git操作进行锁定，并使Git级别的事务看起来是原子的，但是任何在Git之外工作的、与Git的锁定系统不配合的事务，都可以在发生更改时看到更改。

简单的回答是否

值得考虑的是，git pull根本不是关于文件，而是关于提交。文件只是一个副作用。：-pull操作只是git-fetch-get-committes，然后是第二个git命令，通常是git-merge。合并步骤合并提交。如果操作不是快进而不是合并，则合并文件也会产生副作用；然后，当合并或快进完成时，Git对结果提交进行Git签出

---

所以这可以归结为：git签出在操作系统级别是原子的吗？答案是非常响亮的“不”：它在任何方面都不是原子的。在工作树中写入的单个文件使用操作系统级别的写入调用一次写入一个，而这些写入调用不是原子级的。需要创建或删除的文件一次只创建一个。Git确实使用索引，即在工作树上保留选项卡，以尽量减少删除、创建或重写的文件数量。Git还针对其他Git操作进行锁定，并使Git级别的事务看起来是原子的，但任何在Git之外工作的、与Git的锁定系统不配合的事务，都可以在发生更改时看到更改。

首先，在这种情况下，valid是什么意思？我们很难知道，因为我们不知道你想要实现什么。我强烈怀疑，如果您需要在拉取过程中了解文件的状态，那么您正试图完成一些拒绝让git只是一个源代码控制工具的事情。。。因此，什么样的有效手段远不是显而易见的，对这个问题来说非常重要。我可以告诉您，在发生合并冲突的情况下，无论是否以原子方式编写，文件都会停止作为有效代码。您是对的，我添加了一些上下文。希望能有所帮助首先，在这种情况下，有效性意味着什么？我们很难知道，因为我们不知道你想要实现什么。我强烈怀疑，如果您需要在拉取过程中了解文件的状态，那么您正试图完成一些拒绝让git只是一个源代码控制工具的事情。。。因此，什么样的有效手段远不是显而易见的，对这个问题来说非常重要。我可以告诉您，在发生合并冲突的情况下，无论是否以原子方式编写，文件都会停止作为有效代码。您是对的，我添加了一些上下文。希望对汉克斯有帮助。这正是我所期待的。如果有一个选项可以强制在文件上进行原子交换，那会很好，但这可能不是git设计的目的。请注意，您可以使用单独的工作树、单独的索引文件和重命名操作构建自己的原子性，假设您有一个原子重命名。这里的想法是使用一个新的空索引将新的工作树签出到一个空的临时目录中，该临时目录可以与当前树位于同一位置。然后，将正在使用的树重命名为“不妨碍”，然后将新树重命名为“就位”。没有t时有一个简短的窗口

---

ree的，但这是尽可能小，除非你的操作系统提供了交换名称操作。谢谢。这正是我所期待的。如果有一个选项可以强制在文件上进行原子交换，那会很好，但这可能不是git设计的目的。请注意，您可以使用单独的工作树、单独的索引文件和重命名操作构建自己的原子性，假设您有一个原子重命名。这里的想法是使用一个新的空索引将新的工作树签出到一个空的临时目录中，该临时目录可以与当前树位于同一位置。然后，将正在使用的树重命名为“不妨碍”，然后将新树重命名为“就位”。当根本没有树时，会有一个简短的窗口，但除非操作系统提供交换名称操作，否则这个窗口会尽可能小。