iT邦幫忙

2026 iThome 鐵人賽

DAY 4
1

有一種雷包同事,技術爛就算了,抗壓性還極低,動不動就哭。最扯的是,竟然連 git push 這七個字母都會打錯,硬生生下成 git pull,然後把整個 local 搞到衝突爛掉,最後在那邊哭求別人幫忙解 Conflict 大家都在猜他到底怎麼面試進來的,結果發現他是大佬的弟弟。

科技業就是這樣,裙帶關係(Nepotism)哪裡都有。但這在工業工程的視角裡,是極度危險的「未授權操作」。

當一個連版本控制基本概念都沒有、連 Git 指令都能打錯的人,竟然擁有跟 Senior 工程師一樣的系統權限時,這就不是他個人的問題了,這是基礎設施(Infrastructure)管理者的嚴重失職。

雷包在 local 把 Code 搞爛就算了,最可怕的是大佬為了護航,竟然還想把雷包那坨沒有經過完整測試、充滿 Merge Conflict 殘留符號(<<<<<<< HEAD)的 Code 直接推上測試環境

面對這種靠關係進來、連 Git 指令都記不住的未爆彈,唯一的解法就是「最小權限原則(Principle of Least Privilege)」加上「完全隔離的自動化部署」。

絕不能讓雷包有機會從他的 Local 端對任何共用環境造成影響。我們必須用 CI/CD 的防禦工事把他死死關在沙盒裡。

嚴格的 RBAC (Role-Based Access Control) 與環境隔離:
雷包的帳號只配擁有 Development 環境的 Read 權限。想要部署?不准用 CLI 手動下指令,全部給我走 CI Pipeline。

用 Linter 擋下低級的 Git 衝突殘留:
既然雷包連解 Conflict 都會把 ======= 留在 Code 裡面,我們就在 pre-commit hook 或 CI 的第一關,加入針對 Git 殘留符號的 grep 檢查。

name: Dummy Proof Check
on: [pull_request]

jobs:
  prevent_git_conflict_markers:
    runs-on: ubuntu-latest
    steps:
      - name: 檢查原始碼是否有 Git 衝突殘留符號
        run: |
          if grep -rnw 'src/' -e '<<<<<<< HEAD' -e '=======' -e '>>>>>>>'; then
            echo "抓到了 Conflict !"
            exit 1
          fi

上一篇
5:56 的打卡戰神,開會永遠不在,事後才在 Slack 咆哮「為什麼我不知道」的巨嬰
下一篇
下班開直播教 Clean Code,上班自己的 PR 卻像一坨大便
系列文
大廠觀落陰:中年工程師的產線鬼故事與生存防身術 共 18 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言