黑皮考町

Ignore files in Git without using a .gitignore file 在日常開發中，你可能會遇到某些檔案不希望被 Git 追蹤變更，但又不想修改專案中的 .gitignore 檔案。以下我將介紹四種在 Git 中忽略文件（但不使用 .gitignore）的常見方法，並分享每種方法的適用情境與操作方式。 1. 使用 git update-index --assume-unchanged 當你希望暫時忽略某個已經在版本控制中的檔案變更時，這個命令會非常有用。執行下列指令後，Git 會假設該檔案沒有變更，即使實際上已經做了修改。 git update-index --assume-unchanged <file> 如果未來需要取消這個忽略設定，可以執行： git update-index --no-assume-unchanged <file> 這個方法適合用於那些偶爾需要修改但又不希望被提交到版本庫的檔案，例如配置檔案或環境變數文件。 2. 使用 git update-index --skip-worktree 另一個類似的命令是 --skip-worktree 。這個選項通常用於當你需要保留檔案在版本庫中的狀態，但又不希望本地修改被 Git 追蹤。這對於那些會根據個人環境做出調整的檔案尤其適用。 git update-index --skip-worktree <file> 如果想要回復檔案變更的追蹤，則使用： git update-index --no-skip-worktree <file> 與 --assume-unchanged 不同， --skip-worktree 的設計目的是忽略本地修改，特別適用於分支間共享同一份文件而本地配置有所不同的情境 3. 使用 Git Exclude (Per-Repo) 有時候你可能不想讓某些忽略規則進入版本控制，但又希望在本地專案中使用。這時候可以利用 Git 的「排除檔案」功能，把忽略規則放在 .git/info/exclude 裡面。該檔案的語法與 .gitignore 完全相同，但它只會影響當前專案，不會提交給版本庫。 步驟如下： 打開 .git/info/exclude 檔案。 添加你想...

DevSecOps：如何使用 Ansible Vault 在 GitLab CI/CD 中安全管理秘密資訊 前言 以下是關於如何在 **GitLab CI/CD** 中使用 **Ansible Vault** 建立安全的 CI/CD 管道的詳細步驟。這將指導你從加密秘密資訊開始，到設置管道進行部署的完整過程。 準備 1. GitLab 帳戶 ：確保已擁有一個 GitLab 帳戶並且已經設置好一個 repository。 2. 本地安裝 Ansible ：需要在本地安裝 Ansible 來加密/解密秘密文件。 第一步：設置 Ansible 並創建加密的文件 1. 安裝 Ansible ：    首先，確保已在本地機器上安裝了 Ansible。在 Ubuntu 上運行以下命令來安裝它：    ```bash    sudo apt-get install ansible    ```    如果使用其他操作系統，請參考官方的 [Ansible 安裝指南](https://docs.ansible.com/ansible/latest/installation_guide/index.html)。 2. 創建一個秘密文件：    在本地的工作目錄中，創建一個包含敏感資訊的 YAML 文件，例如：    ```yaml    # secret_vars.yml    db_username: myuser    db_password: supersecurepassword    api_key: someAPIkey12345    ``` 3. 使用 Ansible Vault 加密文件：    運行以下命令來加密 `secret_vars.yml` 文件：    ```bash    ansible-vault encrypt secret_vars.yml    ```    系統會提示你輸入一個密碼。記住這個密碼，因為你需要在 G...

  GitLab flow 採用 upstream first policy, 只有一個主要的分支  "master", 當要開發新功能時, 就是從 master 開一條新的分支出來修改, 最後再透過 Merge Request (MR) 把分支合併回 master 發布時, 針對不同的環境建立不同的分支像是 pre-production 以及 production 分支, 透過 cherry-pick 的方式, 將要發布的內容先從 master 合併到 pre-production 的分支上,  當pre-production 測完沒問題後再做一次 cherry-pick 把這些更動內容從 pre-production 合併到 production 的分支上作正式的發布  簡單的說, 所有的更動都是從 master 開分支出來改, 然後才合併到下游分支中 (master > pre-production > production) 結論 GitLab flow 相較於 Git flow 來說不會太過複雜, 沒有一堆分支需要維護, 即使是新進人員也能夠快速地上手, 而相對於 GitHub flow 來說在軟體發布的方面也比較有彈性, 不會被侷限在主分支 master 上, 因此 GitLab flow 等於是集結了 Git flow 以及 GitHub flow 兩者的優點 推薦閱讀 淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part I) 淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part II)

  前言 先前  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part I)  介紹過 Git flow 的分支策略非常複雜, 開發過程中會需要管理許多種不同的分支 develop/feature/hotfix/release/master, 對於需要在短時間內作持續發布的團隊來說並不是很適合 GitHub flow 相反的 GitHub flow 就非常的簡單, 只有兩種分支:  feature 分支跟 master 分支 feature 用來開發新功能 master 用來發布 開發新功能時會從 master 分一條 feature 分支出來改, 改完沒問題後再提交 Pull Request (PR) 到共用的遠端儲存庫, 當審核的人覺得沒問題後,  提交的修改內容就會被合併到 master 上保存 結論 Github flow  非常適合做持續發布, 缺點是因為 master 只會保存最新的版本, 但在某些情況下我們可能會不希望最新的版本馬上被發布出去 下一篇  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part III)

  Git flow 最早被提出的分支策略 由兩個主要分支  master, develop 和三個支援性分支 feature, hotfix, release （暫時性）所構成 基本上, develop 分支會放軟體的最新版本 而 master 分支則是用來放最穩定的版本, 所以軟體要發布正式版本時也會用 master 分支來發布 Feature 在開發的過程中如果要加新功能, 會從 develop 額外拉一條新的 feature 分支出來作新功能, 等功能完成後再合併回 develop 分支裡, 在合併完後 feature 分支會被刪除 Hotfix 當軟體在發佈之後若被發現有 bug, 通常會從 master 分一條 hotfix 分支出來作 bug 修復, 等問題修復完後, 這條 hotfix 分支會被合併到 master 以及 develop 上, 當合併完後也會被刪除 Release 在軟體正式發佈前, 通常會先將軟體預先發布到一個準生產環境中讓 QA 團隊進行測試, 當通過測試之後, release 分支會被刪除 缺點 Gitflow 太複雜了, 有太多的分支需要管理, 不適合對於需要在一天內作多次持續部署的團隊使用 下一篇  淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part II)

前言 實務上在多人開發的情況下, 很常在上 Code 的時候被 Git 要求先做 PULL 但若是 PULL 下來的內容有問題,  特別是當同仁交付了一段會造成系統崩潰的內容至版本庫 (Repository) 時, PULL 下來的 Commit 就會使正在開發的功能受到影響, 若無法在短時間內修正, 嚴重的話甚至會影響到整個軟體專案的開發, 造成其他新功能都無法進行部屬 使用 Revert git pull 做的事情就是 Fetch + merge, 所以事實上可以使用 git revert 把剛剛的 Merge Commit 打掉 找出要打掉的 Merge Commit Id 執行 Revert 指令 $ git revert -m 1 結果如下 使用 Reset $ git reset --hard <MERGE 之前的 COMMIT_ID> 不建議用這個方法, 因為執行完上面的指令之後, 雖然 HEAD 會往前移動, 工作目錄會被還原到合併之前的 Commit, 但是在重新上 Code 時 Git 還是會要求做 PULL, 因為遠端分支的 HEAD 還是指在比較新的 Commit 上(有問題的  Commit) 除非強行覆蓋遠端版本庫中的內容, 如下 $ git push --force 但實務上並不是每個開發團隊都接受使用--force 的指令作強制覆蓋, 所以要取消 Merge Commit, 建議還是使用 Revert 指令

前言 在多人協作開發的情況下, 若想要追查某行程式碼是由哪位工程師在哪個commit下交付的相關資訊, 那我們可以使用以下兩種方法來找出來 git log  git blame 舉例來說: 若想找出./lib/growls.js 當中 exports.isCapable = () 是被交付在哪個commit下 方法一: 使用git log $ git log -S "Code" "<file_path>" 結果如下 exports.isCapable() 這一行程式碼是在Commit Id 360656d.. 裡被Christopher加進來的 方法二: 使用git blame $ git blame "<file_path>" 結果如下 這個方法可以秀出特定檔案中每一行程式碼的交付訊息

前言 Gitlab 是個非常好用的CI/CD工具(平台), 我們將所有要做的事情(如編譯, 測試, 產生docker image)定義在Pipeline裡, 讓 Gitlab Runner 去執行, 進而實現自動化的建置與部屬 而如果自動化的過程中出現問題, 也可以去追蹤輸出的log來找到原因 錯誤訊息 當 Gitlab Runner 執行 docker build 的指令時, 若出現以下錯誤訊息 Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.38/build? ... 表示執行指令的身分沒有足夠權限 由於Gitlab Runner 會以gitlab-runner的身分去執行指令 所以解決方很簡單, 只要把 gitlab-runner 加到docker的群組中就行了 Step 1. (Optional) 若沒有docker群組的話需要建一個 sudo groupadd docker Step 2. 加入 gitlab-runner sudo usermod -aG docker gitlab-runner 最後, 重啟 docker服務或者重開機

前言 隨著雲端服務越來越方便, 相信也越來越多人開始把程式部屬在雲端上了吧, 像是Azure App Service 這種Platform as a Service的雲端服務, 對工程師來說開發時只要把精力專注在寫程式的部分, 而不需要勞心費神地搞伺服器, 拉網路線, 申請SSL的憑證,,,等等. 如果使用得宜, 相信絕對會減少許多開發成本 以下就簡單的介紹如何將NodeJs 的程式部屬到Azure 首先必須在Azure上面建立資源 1. 建立Resource Group 2. 建立App Service Plan 3. 建立Web應用 注意: 如果想將Web應用建立在既有的Resource Group並套用既有的App Service Plan 則可以省略(1)(2)步驟 首先, 登陸Azure並打開Azure Cloud Cli (1) 建立Resource Group管理底下的虛擬化資源(Optional) az group create --name NodeResourceGroup --location "West US" 上面的範例是指定一個美西的位置給NodeResourceGroup, 讓它把底下資源的相關資料(Meta Data)放在這位置上 (2) 建立App Service Plan(Optional) 根據自己的需求決定自己想要怎樣的VM環境, 然後選擇適合自己的Service Plan, az appservice plan create --name NodeAppPlan --resource-group NodeResourceGroup --sku S1 上面的例子裡, 我選擇S1的方案, 一個月大概1200左右台幣, 如果單純想要練習或測試的話,可以選擇Free 的方案 (3) 建立Web 應用 之後我們會將程式會部屬在這邊 az webapp create --resource-group NodeResourceGroup --plan NodeAppPlan --name MyNodeAppAndy --runtime --% "NODE|6.9" 注意, 在官方文件上你...

假設在開發過程當中, 如果某些功能善未完成, 但開發團隊可能需要我目前已經修該好的部分, 這個時候我可以用 git add -A 把所有東西東加上去, 也可以選擇性的commit 相關檔案 假設我只想要commit file_1.txt 使用 git add [想要加的檔案] git add file_1.txt 然後再commit git commit -m "update file_1.txt"