我有一個 git repo 克隆并部署在需要從 GitHub 中的遠程 git 位置定期更新的服務器中。由于不相關的操作原因，我們無法將更新推送到服務器，我們只能輪詢遠程以檢查是否有任何更新。
我們正在考慮通過在執行 git pull 和其他一些操作的 cronjob 上運行更新 shell 腳本來解決這個問題。此腳本是已部署的同一 git 專案的一部分。
我的問題是，讓腳本從它所在的同一個倉庫執行 git pull 是否安全？腳本本身可能會在未來發展和變化，并且會覆寫自己。
我已經進行了一些初步測驗，似乎沒有問題，但我想詢問社區是否存在我們未考慮的副作用或問題。
uj5u.com熱心網友回復：
“安全”是一個主觀術語。以下是不將腳本放在同一個倉庫中的一些（人為的）原因：
- 如果有人在腳本中引入了阻止其自身在未來更新的錯誤，則它可能會卡住并需要手動干預才能修復。
- 如果沒有手動干預，腳本本身可能無法重命名或移動。當腳本未運行時，可能需要更新 repo。
- 如果不法分子獲得了對 repo 的訪問權并以這種方式更改腳本以執行危險操作，則腳本將自動運行。
話雖如此，直接從 repo 運行腳本是很常見的。#1 和 #2 不是在 repo 之外運行腳本的好理由。當然，他們需要手動干預來解決問題，但是將其與將腳本放在存盤庫之外開始進行比較，那么每次您想要更新腳本時都需要手動干預。
關于“安全”，出于安全目的，主要是＃3 是相關的，重要的是要注意，無論您從哪里運行腳本，邪惡的參與者都可以輕松修改代碼的其他方面，這可能會更難檢測和更具破壞性。
權衡這些評論，我會說，是的，通常從 repo 中運行腳本可能是“安全的”。
提示：如果您的服務器沒有在您正在拉取的分支上創建自己的提交，我想提出一個替代方案git pull：
git fetch
git reset --hard @{u}
Note@{u}與分支無關，指的是上游分支，但origin/main如果您愿意，可以將其硬編碼為（或任何您的分支名稱）。
這稍微好一點的原因有兩個：
- 在（希望很少見！）遠程分支被強制推送的事件中，此腳本將繼續按預期作業。如果您使用
pull它，它將嘗試將新強制推送的提交與先前版本的提交合并，這肯定是不可取的。 - 如果您的自動化確實創建了本地提交但它不應該有怎么辦？然后，當您拉動時，您將再次獲得合并提交。
另一種可能的選擇是更改git pull為：
git pull --ff-only
執行此操作與重置之間的主要區別在于，即使出現上述 2 個潛在問題，重置每次都會起作用。在這pull --ff-only兩個潛在問題中的任何一個上都會出錯，而不是可能默默地成功并產生不希望的結果。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/441089.html
上一篇：變基以從分支中洗掉不需要的提交