如何使用 Git 让某人被解雇

2025-05-25

如何使用 Git 让某人被解雇

这是比利。

带着微笑和一条红领带的简笔画
他是一家重要公司的实习开发人员。

不幸的是,对于公司来说,今天比利醒来后选择了暴力。

这是因为他觉得学习Git很麻烦、很枯燥、很复杂。

分支、提交、检出、HEAD、功能、暂存,天哪!

这对他来说实在是太过分了。

但后来比利却有了绝对最好、最糟糕的想法。

“如果我学习 git 时首先学习什么不该做,然后无论如何都要去做,会怎么样呢!”

这将实现三件事:

  1. 他会通过给自己设置一些通常会被禁止的有趣的小挑战来学习 git 最常用的工具。
  2. 如果他知道什么不该做,他就可以集中精力做他应该做的事情。
  3. 这样学习满足了他混乱邪恶的倾向。

对比利来说,这听起来越来越像个好主意了。这肯定会让他成为一名更优秀的开发人员。

但只有一个问题……

Git 是开发人员用来管理软件源代码的版本控制系统。

无论何时有人更改、添加甚至删除某些内容,Git 都会记录谁做了什么。

如果你想在你所在公司拥有的存储库中做一些非常坏的事情,那么总会有人追踪到你。

这肯定会让你被解雇。

这就是比利偷特伦特电脑的原因。

火柴人比利拿着一台写着“

特伦特是个大傻瓜,他去洗手间时忘记关电脑,也没有采取任何保护措施。

上个月的聚会上,他还未经允许就吃掉了最后一片披萨。

通过特伦特的计算机,比利现在可以访问相同的存储库,但需要使用特伦特的登录凭据。

现在 Billy 可以通过首先学习所有他不应该做的事情来学习 Git,例如:

1. 使用 --force 将代码推送到其他人的分支

假设当前的 git 生态系统如下所示:

主分支和同事的功能分支的 Git 图表。

Billy 目前正在检查另一位同事分支的早期版本。

如果两个人在同一个分支上签出,但其中一个人开始将更改推送到远程,就会发生这种情况。

这意味着 Billy 在分支上落后了。如果他想获取当前所在分支的最新更改,可以在终端中输入git pull

有趣的事实:
Git pull 实际上是另外两个 git 命令的组合。

  • git fetch origin(获取远程的最新更改,无需签出或合并)
  • git merge origin/<branch name>(这会将你的本地更改合并到远程。由于通常你没有本地文件需要合并,git 会执行所谓的“快进”,最终你会得到最新的更改)

比利想知道如果他尝试推动这个人的分支会发生什么,即使他落后于最新的变化。

通常,如果他尝试git push某些代码,尝试将会失败并出现错误 - 要求他首先提取最新的更改。

(这是 git 内置的安全网,可以避免工作丢失。除非先拉取,否则无法推送!)

但如果 Billy 发出命令,他就可以避免这种情况git push --force

git push --force对开发者来说,这通常是一个大忌。这个命令会强制覆盖 git 历史记录,并允许你推送本地更改,尽管它可能会删除同一分支上其他人的工作。

比利以前从未使用过它,而且他是一个好奇的男孩,所以他做了任何好奇的人都会做的事情。

  1. 他创建了一个新文件,里面有特殊文本:
    echo "Trent was here" > Trent.txt

  2. 他向分支机构提交了非常重要的变更
    git add Trent.txt
    git commit -m "Trent committed this"

这使得 git 看起来像这样:

Git 流程图展示了 Billy 的同事所做的更改如何消失,以及他用新代码如何覆盖它

  1. 最后,他强制将新的更改推送到分支git push --force

几秒钟后……

噗!

Billy 非常重要的改变现在在 Git 中!

与此同时,他所有同事的工作成果都彻底消失了!

如果 Billy 用过的话git push --force-with-lease

--force-with-lease是该命令的更安全版本--force。它可以防止 Billy 覆盖同事在远程设备上的工作。

算了!木已成舟。说到底,玩得开心才是最重要的。

比利想知道他还要多久才能让那位同事注意到。

他还想知道自己还能做些更糟糕的事情吗?也许……他可以在生产部门做类似的事情?

比利突然灵光一闪!如果他做了以下事情会怎么样?

2. 在生产分支上进行硬重置

Git reset是一个命令,类似于 Billy 对他的同事所做的命令,撤消在分支中对上一次提交所做的更改。

与他之前学到的命令不同git push --force,它不需要推送任何内容。它只是通过(通常)取消提交到某个提交之前的所有操作来重写 git 历史记录。

git reset 命令有 3 种模式。

  1. git reset --soft这会将 HEAD(Head 表示当前检出的提交)移回指定的提交,同时撤消所有更改。所有这些更改都会返回到暂存状态,并允许您再次提交。

  2. git reset --mixed其作用与 相同git reset --soft,但会保留所有未暂存的更改。这也是 git reset 命令的默认模式。因此,如果您输入git reset,则与 相同git reset --mixed

  3. git reset --hard简直太糟糕了。它不会撤消更改并将它们保留在暂存/未暂存状态……而是直接丢弃它们。

当您硬重置为旧提交时,所有这些更改都会消失。

因此,如果 Billy 说...硬重置为6 个月前的提交,哦,我不知道,这对公司来说非常糟糕。

比利微笑着打开终端。

回顾一下 git 生态系统的样子:

Git 分支显示 6 个月前的提交和最新的提交

比利高兴地开始说:

  1. 在终端中输入内容git checkout main,定位到该分支的最新提交。

  2. 使用 git 可视化工具从主分支中查找 6 个月前的提交。

  3. 类型git reset --hard <commit hash>用于在本地删除主分支中过去 6 个月的所有更改。

  4. 最后,利用我们的好朋友git push --force将他的本地破坏性变化永久地留在远程。

几秒钟后……

噗!

比利成功让一些公司高管非常非常生气!

但是等一下...

比利能做到这一点,真是奇怪,不是吗?毕竟……

权限通常在存储库中设置,以便没有人可以直接推送到生产分支。

这可以防止意外推送或重写直接影响网站的 git 历史记录。

这就是为什么存在所谓的“拉取请求”(或 PR)。

拉取请求是将一组更改从一个分支合并到另一个分支的提议。

通常情况下,其他精通技术的开发人员必须先接受您的更改,然后您才能合并。

但是如果从未设置这些权限会发生什么?

好吧,似乎任何像比利这样的人都可以在一秒钟内抹去大家在过去两节的辛勤努力。

他估算自己大概还有 10……不,15 分钟的时间,之后他的改动就会对生产产生主要影响。

所以比利必须迅速行动。在一个叫特伦特的人惹上麻烦之前,他可能还有时间再做一件混乱邪恶的事情。

该怎么办...

哦,比利知道!他应该:

3. 公开项目的秘密并将其推向生产!

Billy 可以通过修改 .gitignore 文件轻松地做到这一点。

.gitignore 是位于项目目录中的一种特殊文件。顾名思义,它指定 Git 应该忽略哪些文件,避免让你暂存它们。

当您有一些特定的文件根本不想上传到存储库时,这非常有用。

您通常要避免上传的文件之一是 .env 文件。

.env 文件通常在项目中用于保存在整个解决方案中使用的环境变量。

它们以键/值对的形式存储着你绝对不想上传的信息,例如 API 密钥、数据库 URI、AUTH 机密等等。

但比利不相信保守秘密。

他是他的故事中的英雄,必须让人们知道!

因此,如果我们假设我们的 .gitignore 文件如下所示:

# Javascript node_modules
node_modules/

# API keys
.env
Enter fullscreen mode Exit fullscreen mode

那么 Billy 要做的就是:

  1. 找到 .gitignore 文件

  2. 使用他最喜欢的 IDE 或终端文本编辑器从文件中删除 .env 行并保存。(现在文件看起来像这样)

    # Javascript node_modules
    node_modules/
    
    # API keys are gone from ignore oops
    
  3. git add .gitignore将修改后的 .gitignore 文件添加到暂存区。Billy 在终端中输入

  4. 哦,等等!别忘了——既然 Git 现在没有忽略 .env 文件,Billy 也必须添加它!git add .env也输入到了终端中。

  5. 是时候做出承诺了!Billy 用这句台词来表达:

    git commit -m "FREEEEEEDOOOOOMMM!!!! #TrentWasHere"

  6. 最后一步!是时候推送到主分支了。同样,由于某种原因,Billy 没有设置任何权限阻止他写入git push --force终端。

几秒钟后……

噗!

“自由、平等、博爱!”比利高兴地低声说道!说完,他把特伦特的电脑放回了原处。

这也是件好事,因为他刚刚听到了房间里传来的马桶冲水的声音。

比利跑回他的办公桌,及时赶到,以免被人注意到。

看来特伦特终于从洗手间回来并坐在了办公桌前。

但就在他打开笔记本电脑之前,特伦特的电话就开始响了。

铃铃铃,铃铃铃

当比利看到特伦特慢慢拿起手机时,他满怀期待地等待着。

“你好?”

“特伦特。办公室。现在。”

比利在 5 张桌子之外就能听到特伦特手机里的叫喊声。

“哇哦,老板,发生什么事了?”

...

“我没有做任何类似——”

...

“你怎么了,生产出了什么问题?

...

“我正在路上”

特伦特迅速跑进办公室,这可能是他一生中发出过的最大声的尖叫声。

比利坐下来,放松下来,终于可以说:

“今天我是一个更好的开发人员”。

火柴人比利正在微笑


这是我写过的最愚蠢的文章。

如果您喜欢我的幽默感,那么我想您会喜欢我的时事通讯“Exceptional Frontend”——网络上最有趣的前端时事通讯。

它适合所有想要一份以前端为中心、与众不同的新闻通讯的开发者。我们倾注了大量精力,力求让它独一无二,最重要的是——好玩!

同时也帮助开发人员在他们的工作中变得卓越。

您可以在此处注册。

文章来源:https://dev.to/mauroaccorinti/how-to-get-somebody-fired-using-git-31if
PREV
您从未听说过的新的(和旧的)CSS 单元现在有一些更轶事...
NEXT
理解虚拟 DOM 的最佳示例