Git

一個關於如何在Netlify functions中使用環境變數的簡要指南。 要在 Netlify Functions 中使用環境變數，可以訪問 process.env 變量： process.env.YOUR_VARIABLE 您也可以在JS文件的開頭使用對象解構，使代碼更加精簡： const { YOUR_VARIABLE } = process.env; 因此，在程序的其餘部分中，您只需要使用 YOUR_VARIABLE。 您可以通過Netlify管理介面來設置這些變量（您也可以將它們添加到代碼庫中，但我建議使用Netlify界面，這樣您的Git存儲庫中就不會有任何機密信息）。 注意：這種方法不適用於Netlify Edge Functions，僅適用於在AWS Lambda上運行的Netlify“常規”Functions。 對於Netlify Edge Functions，您需要使用 Deno.env.get()，像這樣： Deno.env.get('YOUR_VARIABLE') 示例： export default () => new Response(Deno.env.get('YOUR_VARIABLE'))

在 Netlify 上部署基於 GitHub Pull Request 的網站版本的逐步教程 我當時正在準備推出一門課程，我需要在「發布日期」上完成登陸頁面，但同時又不更改我當時對外公開的版本。 我使用的是 Netlify，它可以從 Git 分支自動部署網站，我的情況是在 GitHub 上進行託管。我將記錄這個過程。其他基於 Git 存儲庫進行 CI/CD 的託管提供商可能也有類似的工具。 Netlify 會自動為 Pull Requests 創建部署預覽。 所以，我創建了一個新的分支，我稱之為 launch，然後在該分支上進行工作，添加了一些提交，然後我創建了一個 Pull Request，GitHub Desktop 讓這個過程變得非常簡單： 在我發送 PR 後，Netlify 開始進行持續集成/持續交付流程： 轉到 Netlify 網站後，我可以看到它自動選取了 Pull Request 分支並開始了部署預覽： 幾分鐘後，我得到了一個新的網站 URL，我利用它進一步準備課程上線，而主域名仍然指向 master 分支的代碼。

一個從零開始設置 Git 和 GitHub 的教程 Git 是一個非常有價值的工具。 它允許我們在項目上工作數月或數年，但仍然能夠回到我們在代碼庫上做出的每一次個別變更。在團隊中，你還可以找出是誰進行了更改。 每次我們進行更改、添加新功能或修復錯誤時，我們都會添加一個小的解釋，然後我們提交這些更改。 它還允許我們與團隊合作，因為每個人都可以將提交推送到代碼庫，Git 會負責確保與其他人所做的更改沒有衝突。 在繼續之前，你需要在你的電腦上安裝 Git。 最簡單的方法是安裝GitHub Desktop應用程序。 它適用於 Windows 和 Mac，你可以在這裡下載它： GitHub Desktop 這將安裝一個用於使用 Git 的圖形用戶界面，同時也安裝了 Git 本身。 它與 GitHub 緊密集成。 GitHub 是什麼？🤔 它是一個用於托管代碼並讓你在開源項目上協作的網站，你將在這個項目的所有實例中使用它，而且這也是你將看到我發佈的項目代碼的地方。 安裝完畢後，打開應用程序。 點擊“Create your free account”。你會被帶到 GitHub 上創建一個帳戶： 明智地選擇用戶名，你將擁有一個公開的 GitHub 頭像，就像我在這裡： https://github.com/flaviocopes 確認你的電子郵件後，你會看到一個畫面，點擊“Skip personalization”並選擇自由計劃： 最後，你進入了： 現在回到 GitHub Desktop 應用程序，點擊“Sign in to GitHub.com”，即藍色按鈕： 最後，你準備配置 Git。接受這一點以設置 Git 的用戶名和電子郵件，這是你創建提交所需要的。點擊“Finish”。 安裝此應用程序同時也安裝了 Git，所以你不需要再做其他任何操作。 注意：如果你喜歡，你可以從這裡下載“只有 Git”https://git-scm.com/downloads，這將跳過 GitHub 的集成。使用這種方法，你需要使用下面這兩個命令在終端中設置你的名字和電子郵件： git config --global user.name "你的名字" git config --global user....

我有這個需求。我想要創建一個現有網站的完全複製品，並將其放在一個子域名下，作為存檔。 現在這個網站已經使用版本控制，我想要保留 Git 的歷史記錄，但也想要將其部署到一個新的 GitHub 倉庫，這樣我就可以將它們分開部署了，現在兩個網站可以各自有自己的命運。 這個網站是一個 Hugo 網站，所以我只需將網站文件夾複製到另外一個文件夾中即可，這樣在本地完成了。 然後我進入複製後的網站文件夾，在終端中運行以下命令： git remote -v 這將列出現有的 GitHub 倉庫作為「origin」遠端倉庫。 然後我運行： git remote rm origin 這將刪除 origin 遠端倉庫，這樣運行 git remote -v 將不再返回任何結果。 現在，由於我使用 GitHub Desktop，我只需將該文件夾拖放到該應用程序中，然後就能從那裡創建一個新的、不同的 GitHub 倉庫了。

在使用命令行執行 Git 時，最常用的身份驗證方式是使用 SSH 金鑰。了解如何設置它們。 在使用命令行執行 Git 時，最常用的身份驗證方式是使用 SSH 金鑰。 大多數基於圖形界面的客戶端（如 GitHub Desktop）會幫你處理這個問題，但有時你需要使用命令行，所以設置好 SSH 金鑰非常有用。 此外，有時您需要一個 SSH 金鑰來執行一些有用的操作，例如在遠程服務器上拉取存儲庫。 您的電腦上的金鑰 SSH 金鑰存儲在 ~/.ssh 文件夾中。 您可以在其中擁有多個金鑰，因為 SSH 金鑰用於除了 Git 之外的其他事情。 您可以通過輸入以下命令列出所有 SSH 金鑰： ls -al ~/.ssh 如果您有現有的金鑰，您會注意到它們是成對存在的，一個文件和另一個以 .pub 結尾的名稱相似的文件： .pub 文件包含公鑰，而另一個文件包含私鑰，私鑰絕不應在任何地方共享。 您絕不能共享私鑰。如果您丟失私鑰，您將不得不重新生成新的私鑰/公鑰對，因為沒有私鑰部分身份驗證將無法成功完成。 生成新金鑰 您可以使用命令 ssh-keygen 生成新的 SSH 金鑰，該命令在所有 macOS、Linux 和具有 Linux 子系統或Git for Windows 包的現代 Windows 電腦上都可用。 下面是您使用的命令： ssh-keygen -t rsa -b 4096 -C "[[email protected]](/cdn-cgi/l/email-protection)" 最後一部分，在這個例子中填寫了一個電子郵件地址，這是一個註釋。您可以輸入任何您想要的電子郵件，它不必是您的 GitHub 帳戶，甚至可以是一個隨機字符串。如果存在歧義，了解是誰生成了金鑰可能是有用的。 密鑰生成程序會問您希望將密鑰保存在哪裡。如果這是第一個金鑰，建議使用 id_rsa 作為文件名，但最好選擇一個能讓您記住所生成的服務的名稱，比如 github_rsa。...

這是一個很好的問題。有利有弊。我討論這個話題，讓您可以對此做出自己的意見。 應該在 Git 中提交 node_modules 文件夾嗎？ 我提到了 Git，但同樣的原則也適用於您所使用的任何版本控制系統。 這是一個很好的問題。有利有弊。 我建議的默認選擇是不提交 node_modules 文件夾，而是將其添加到您的.gitignore文件中。 您可能有特殊的需求，反過來改變這個決定。 我討論這個話題，讓您可以對此做出自己的意見。 以下是不提交 node_modules 的一些論點： 您可以保持 Git 歷史純淨。當您添加新的套件時，您只需存儲package.json和package-lock.json文件的更改。當您決定更新套件版本時，只需存儲package-lock.json的文件更改。 package-lock.json是 npm 的一個相對較新的功能，它取代了以前使用的“shrinkwrap”命令。 您避免將數百MB的依賴項放入您的存儲庫中，這意味著隨著時間的推移，工作速度將更快。切換分支和檢出代碼是受存儲庫大小影響很大的2個操作。 在使用分支時，您可能會遇到超出您的代碼範圍的合併衝突，而是涉及依賴代碼。這對您處理來說並不好，可能會浪費很多時間。避免提交更改依賴項後的合併請求或合併操作，將有更多的文件涉及到這個過程。工具變得更慢，甚至可能決定不顯示完整的差異（例如 GitHub）。 如果您在部署到與開發機器不同的平台時（常見情況是在 Mac 上開發，在 Linux 上部署），需要重新編譯原生的 Node 模塊。您需要調用npm rebuild，這會使服務器與開發機器不同步。 不提交 node_modules 意味著您需要將所有模塊列在package.json（和package-lock.json）中，這是必須的步驟。這很好，因為您可能不會很注意這樣做，如果您不這樣做，某些 npm 操作可能會出錯。 提示：在package.json文件中不需要使用具體版本，自從引入了package-lock.json文件以後不再需要了。 如果您使用單獨的dependencies和devDependencies集合，通過提交node_modules文件夾，您基本上提交了devDependencies，而生產構建無法（輕易）去除它們。 可能會導致您提交 node_modules 的原因，以及如何解決它們： npm套件可能被其作者從 npm 注冊表中刪除。在 2016 年發生過著名的left-pad事件（了解更多）。這在受歡迎的套件中非常少見。如果發生這種情況，您可能無法再使用那個特定的功能。 您還可以主張npm不能保證無限期存在，它可能會消失，所以確保將完整的代碼與您的應用程序一起提交，是確保將來擁有的一種簡單方法。 每次使用套件時，在 GitHub 上創建一個 fork。偶爾保持它與原始庫同步（可以自動化）。 這在某些情況下並不實用，因為套件可能有數十個它們自己的依賴項。 您可以為項目使用私有存儲庫服務器，並將其用於托管所有依賴項。 選項包括： sinopia npm_lazy npm-lazy-mirror artifactory npm Enterprise（來自 npm 公司） 提交依賴項的另一個原因是能夠快速編輯代碼，如果您發現錯誤或者想要向庫添加某些內容。 這是一把雙刃劍：如果這樣做，您就失去了升級套件的能力，如果有新版本發布，這只對於快速的臨時修復有好處。 最佳的解決方案是要麼向原始項目提交要求的 PR，要麼 fork 它並將您的 fork 用作依賴項。

當你有一個準備好的應用程式時，就該部署它並讓它可以從網上任何地方存取！ PHP 是在網上部署方面，擁有最佳成敗故事的程式語言。 相信我，其他每一種程式語言和生態系統都希望自己和 PHP 一樣容易。 PHP 的優點、它準確理解並允許取得這令人難以置信的成功，是即時部署。 你把一個 PHP 檔案放在 Web 伺服器服務的資料夾中，它就能正常運作了。 不需要重新啟動伺服器，執行可執行檔，什麼都不需要。 這仍然是眾多人的做法。你以 3 美元每月租用一個共享主機，透過 FTP 上傳檔案，完成。 然而，如今我認為 Git 部署是每個專案都應該內建的東西，而共享主機應該過時了。 其中一種解決方案是始終擁有自己的私有 VPS（虛擬私有伺服器），你可以在 DigitalOcean 或 Linode 等服務中取得。 但是管理自己的 VPS 可不是開玩笑的，它需要嚴重的知識和時間投資，以及持續的維護。 你還可以使用所謂的 PaaS（平台即服務），這些平台專注於處理所有煩人的事情（伺服器管理），你只需上傳應用程式，它就運行起來。 像 DigitalOcean App Platform（不同於 DigitalOcean VPS）、Heroku 和許多其他平台均非常適合進行初步測試。 這些服務允許你連接 GitHub 帳號，每次將變更推送到你的 Git 儲存庫時都會部署。 參考 從零開始設定 Git 和 GitHub 這比 FTP 上傳更好的工作流程讓我們一起來做一個極簡的示例。 我建立了一個簡單的 PHP 應用程式，只有一個 index.php 檔案： <?php echo 'Hello!'; ?> 我在 GitHub Desktop 應用程式中添加了上層資料夾，初始化了一個 Git 倉庫並且將它推送到 GitHub： 現在請前往 digitalocean....