作为git中的noob，我不知道如何将当前修改的文件与原始文件(即第一个git克隆(进行修补。有没有人在这个开发软件版本控制方面经验丰富的专家，主要是patch和diff，用于作为合作者(在fork、PR等中(工作，以便解释正确的方式？
制作补丁
只需将git diff的输出保存到一个文件中，就可以创建一个表示所有未提交更改的补丁：
git diff > my-changes.patch
这个补丁只是一个文件，所以你可以通过电子邮件将其发送给某人，或者将其保存在拇指驱动器上，或者用它做任何你想做的事情(我不知道你为什么需要这样做，但你可以(
然后，可以通过应用补丁
git apply my-changes.patch
您通常不需要手动制作补丁，当您确实需要制作补丁时，它们应该始终来自预先存在的提交
补丁可以从预先存在的提交中生成，如下所示：
git diff <start commit>..HEAD > my-changes.patch
这将创建自<start commit>以来所有更改的补丁。您还可以将<start commit>指定为分支、标记(指特定提交(或类似main~10的特定内容(指10次提交前的主分支(。
# Get a patch of all changes that haven't been pushed
git diff origin/main..main > local-changes.patch
# Get a patch of all changes on feature-branch
git diff main..feature-branch > changes-on-feature-branch.patch
# Get the last 10 commits as a patch
git diff main~10..main > last-10-commits.patch
# Get all the changes since a particular tag
git diff v1.0.0..main > changes-since-v1.0.0.patch
再一次，你通常不需要手动创建补丁作为一种工具，git diff对于探索历史、查看当前更改、查看将被合并的更改或一百万种其他用途非常有用。它以一种可以直接应用git apply的形式输出内容，但我一生中从未手动向某人发送过补丁。
以正确的方式在git中进行协作
有三种典型的协作方式，我将从最简单到最高级列出。
方法1：多个合作者，他们都可以访问
这是你在学校或大多数工作环境中看到的最典型的情况。每个人都可以将代码推送到同一个存储库。
一旦你的机器上有了回购的副本，工作流程如下：
对代码进行更改或更新
提交您的更改：
git add <your changes> && git commit在上传之前，您可以进行任意数量的提交。最好的做法是在每次完成一段重要的代码(如函数或类(时进行小规模的提交。
下载远程更改：
git pull如果您的合作伙伴或同事已经用更改更新了存储库，则必须在推送之前执行此操作。这允许您进行检查，以确保您的更改能够与它们的更改一起工作。
上传您的更改：
git push
方法2：你正在处理别人的开源项目
您并不总是能够直接推动您的更改。例如，如果你正在处理一个开源项目，你通常会提交更改以供审查，而维护者将是合并它们的人。
这通常是通过分叉项目、进行更改、将更改上传到存储库(分叉版本(，然后提交拉取请求以将更改集成回原始项目来完成的。
它看起来像这样：
- Fork(在github、gitlab或其他服务上
- 将分叉版本克隆到本地计算机上
- 进行更改
- 提交您的更改
- 推动您的更改
- 创建一个拉取请求，将您的更改合并回中(您可以在github、gitlab或您分叉repo的任何地方执行此操作(
方法3：将提交作为补丁通过电子邮件发送
这种方法通常用于较大、较旧的开源项目，这些项目不想依赖github或gitlab这样的集中式服务。
这是通过使用git send-email直接从命令行通过电子邮件发送补丁来完成的。Git会自动为您创建一个补丁。您所要做的就是指定要作为补丁发送的提交范围。
例如，如果您在一个名为dev的本地分支上进行了更改，那么您将像这样使用它：
git send-email --compose --from=<your email> --to=<their email> master..dev
这里，master..dev是您发送的补丁的范围。dev分支上的所有补丁都不在master分支上。AKA，你的改变。
这个命令将打开一个文本编辑器，您可以在其中编写电子邮件正文，git将把补丁附加到电子邮件上并发送。
请注意，您必须将电子邮件配置为使用git-send电子邮件。初学者通常不需要这样做。