git 拉原子寫文件

Question

我在文檔中找不到任何內容。 如果我執行 git 拉取，我是否保證合並產生的基礎文件是原子寫入的？

關於我要實現的目標的更多背景信息：我有一些腳本會定期執行 git 拉取，我需要知道我是否可以依賴 state 文件在拉取期間有效。

我們基本上使用 git 作為部署工具。 我們從來沒有設計的合並沖突。 在遠程端，一個作業每隔 x 秒不斷拉取一次，其他作業讀取文件。 可能發生的情況是我們在 git 拉取文件時打開了一個文件，而文件的內容不是我們所期望的。 這是除非 git 足夠聰明，可以在底層操作系統上使用一些原子交換（在這種情況下是 RedHat）

Answer 1

簡短的答案是否定的 。

值得考慮的是git pull根本不是關於文件，而是關於commits 。 文件只是一個副作用。 :-) pull操作只是git fetch （獲取提交），然后是第二個Git命令，通常是git merge 。 合並步驟合並提交 。 如果操作不是快進而不是合並，那么這也會合並文件。 然后在合並或快進完成后，Git會對結果提交進行git checkout 。

因此，這實際上可以歸結為： git checkout在操作系統級別上是原子的嗎？ 答案是非常響亮的：絕不是原子的。 使用OS級別的write調用（不是原子的）一次寫入一個寫在工作樹中的單個文件。 一次創建或刪除需要創建的文件。 Git 確實使用了索引（該索引對工作樹進行索引（即保持在其上）），以最大程度地減少刪除，創建或就地重寫的文件數量。 Git還會鎖定其他Git操作，並使Git級別的事務看起來像原子的-但是在Git外部進行的任何工作（與Git的鎖定系統不配合）都將能夠看到更改。

Answer 2

在 git git pull的git checkout部分，請參閱torek的回答。

在git fetch部分git pull上，有一個 --atomic atomic ，Git 2.36 (Q2 2022) 闡明了它。

“ git fetch ” ^{( man )}可以進行兩次單獨的獲取，但是來自它們的 ref 更新在“ --atomic ” 下的兩個單獨的 ref 事務中，已通過 Git 2.36（2022 年第二季度）進行了更正。

請參閱提交 583bc41 、 提交 b3a8046 、 提交 4f2ba2d 、 提交 62091b4 、 提交 2983cec 、 提交 efbade0 、 提交 2a0cafd （2022 年 2 月 17 日），作者： Patrick Steinhardt ( pks-t ) 。
^{（由Junio C Hamano 合並gitster 提交 851d2f0，2022年 3 月 13 日）}

fetch ：增加 fetches 的測試覆蓋率

^{簽字人：Patrick Steinhardt}

當使用帶有--atomic標志的git fetch時，期望所有引用都被更新，或者沒有引用以防 fetch 失敗。

雖然我們已經對此進行了測試，但我們沒有任何測試在修剪已刪除的引用或回填標簽時執行原子性。
測試覆蓋率的差距掩蓋了我們確實沒有正確處理這兩種情況的原子性。

添加覆蓋這些測試差距的測試用例，以演示損壞的行為。

---

警告：

在 Git 2.36（2022 年第 2 季度）中，恢復“刪除 ref 不應單獨觸發松散和打包 ref 后端的事務事件”，這會在 ref 自打包后未修改時回歸行為。

請參閱Junio C Hamano ( gitster )的提交 4315986 、 提交 347cc1b和提交 c6da34a （2022 年 4 月 13 日）。
^{（由Junio C Hamano 合並gitster 提交 4027e30，2022年 4 月 14 日）}

4027e30c53 ：合並分支'jc/revert-ref-transaction-hook-changes'

恢復“獲取：增加獲取的測試覆蓋率”
恢復“合並分支‘ps/avoid-unnecessary-hook-invocation-with-packed-refs’”