想必你也见到过很多开源项目中的 CONTRIBUTION.md 文档中通常都会让贡献者 Fork 仓库，然后做修改。
那么如果你是该开源项目中的成员是否需要 Fork 仓库进行修改呢？
以前我没有认真去想过这个问题，对于项目成员感觉 Fork 或不 Fork 好像差不多，但仔细想想 Fork 仓库与不 Fork 仓库其实是有以下几个主要的差别的：
修改权限
在原始仓库中，你可能没有直接修改代码的权限，当你 Fork 一个仓库时，会创建一个属于你自己的副本，你可以在这个副本中拥有完全的修改权限，你可以自由地进行更改、添加新功能、解决bug等，而不会对原始仓库产生直接影响。
做实验性的工作
如果你计划进行较大的修改或实验性工作，并且不希望直接影响原始仓库，那么 fork 仓库并在 fork 的中进行修改更为合适。
比如你需要实验性的去大量清理现有仓库里的一些垃圾文件或是代码，如果你需要需要多次尝试，并将多次修改直接 git push 到推送原始仓库进行保存或是测试，这大大增加原始仓库的存储空间，如果你的修改是大型文件，那么对原始仓库的存储空间影响则会更大；如果你是 Fork 仓库则不会造成原始仓库的影响，直到你完成修改通过 Pull Request 合并到原始仓库时才会产生新的存储空间。
代码审查和协作
当你 Fork 一个仓库并在自己的副本中进行修改后，你必须通过 Pull Request（PR）向原始仓库合并修改，有助于确保代码质量和功能正确性。（当然不 Fork 也可以这样做或不做，但 Fork 了就必须这样做了）
版本控制和历史记录
Fork 一个仓库后，你可以在自己的副本中维护独立的版本控制历史。你可以跟踪自己的更改、回溯历史、管理代码版本，而不会影响到原始仓库的版本控制。同时，你可以从原始仓库同步最新的更改，保持你的副本与原始仓库的同步。
总结
Fork 仓库与不 Fork 仓库的主要差别在于修改权限、做实验性的工作、代码审查和协作，以及版本控制和历史记录。
个人认为只要一个仓库的贡献者超过 3 人，都建议所有人都 Fork 原始仓库，通过 Pull Request 方式合并代码。
但也有例外情况可能不适合 Fork：项目在 Fork 之后 CI/CD 无法独立工作，但是你需要它们。比如 Fork 后的仓库因为环境等原因不支持独立的运行 CI/CD 而你需要在提交 Pull Request 之前通过自动化对分支进行测试。
另外还要为原始仓库需要做适当的分支权限设置，以防止就算两个人的团队另外一个人不熟悉 Git 使用了非常危险的操作，比如强制推送（Force Push），变基（Rebasing），强制检出（Force Checkout）可能导致代码丢失、数据损坏或版本控制问题。
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」