由diff和git diff创建的补丁/文件有什么不同？
我想知道diff和git-diff创建的文件/补丁的格式有什么不同。
我知道在diff中有3个（“普通”、“紧凑”-c和“统一”-u）。
- 是否可以对同一文件使用
Git diff和diff？ - 格式之间有什么不同？
- 如果不能交换命令（请参见1。）如何将文件转换为其他格式以便与其他命令一起使用？
- 如果可以交换命令（请参见1.):是否建议这样做？
- 这两个命令创建的文件是否有其他显著差异？
共有1个答案
- 是否可以对同一文件使用
Git diff和diff？
简单地说，如果该文件位于git repo工作树中，那么您就可以使用git diff来显示该文件的更改（针对git repo引用的相同文件，如索引或blob对象）。
这与“diff”不同，后者比较文件（这意味着您需要两个文件，而不是像git repo中使用的git diff中那样只有一个文件）
正如hvd在评论中指出的：
git diff --color-words --no-index file1 file2
Git diff可以模拟任何diff格式(unified,raw,...）。
它还具有特定于Git的格式(--summary,--stat,...）
另见：
文档/diff-format.txt- “如何从
Git diff读取输出？”
如果您没有安装git（请参见前面的示例）
否：应用由diff或git diff生成的修补程序的结果应该是相同的。
-
本文向大家介绍svn 创建和应用补丁，包括了svn 创建和应用补丁的使用技巧和注意事项，需要的朋友参考一下 示例 补丁程序是一个文件，它显示两个修订版本之间或本地存储库与您的存储库指向的最新修订之间的差异。 要共享或保存您的本地未提交更改的补丁以供同行评审或以后应用，请执行以下操作： 要从两个修订版之间的差异中获取补丁，请执行以下操作： 要应用补丁，请运行： 为了成功应用补丁程序，必须从创建补丁程
-
之前各个章节版本库间的交互都是通过git push和/或git pull命令实现的，这是Git最主要的交互模式，但并不是全部。使用补丁文件是另外一种交互方式，适用于参与者众多的大型项目进行分布式开发。例如Git项目本身的代码提交就主要由贡献者通过邮件传递补丁文件实现的。作者在写书过程中发现了Git的两个bug，就是以补丁形式通过邮件贡献给Git项目的，下面两个链接就是相关邮件的存档。 关于Git文
-
使用JSONAPI1.0标准设计API，没有PUT方法。只有用于创建资源的POST方法和用于部分更新的修补程序。我们有这样的用例：用户可以向服务器发送请求，如果资源不存在，则必须创建资源，否则必须更新资源。RFC将这种方法描述为PUT。接下来引用提到的RFC5789标准补丁有信息： “如果Request-URI没有指向现有资源，服务器可能会创建一个新资源，具体取决于补丁文档类型（是否可以在逻辑上修
-
问题内容： 我有两个档案 秒杀 test_spike.py： 当我运行时，第一个测试用例将通过，但是第二个将失败。而我切换到use ，则两个都失败了。 我不明白这是怎么发生的？这些情况本应全部通过。 问题答案： 对于 test_foo， 您没有正确使用补丁。您应该像这样使用它： 这给了我： 现在，第二个示例不起作用，因为您导入了bar函数（获取对其的引用），然后尝试对其进行模拟。模拟某些内容时，您
-
Git 中的一些命令是以引入的变更即提交这样的概念为中心的，这样一系列的提交，就是一系列的补丁。 这些命令以这样的方式来管理你的分支。 git cherry-pick git cherry-pick 命令用来获得在单个提交中引入的变更，然后尝试将作为一个新的提交引入到你当前分支上。 从一个分支单独一个或者两个提交而不是合并整个分支的所有变更是非常有用的。 在 变基与拣选工作流 一节中描述和演示了
-
有的时候，需要将对代码的改动以补丁文件的方式进行传递，最终合并入版本库。例如直接在软件部署目录内进行改动，再将改动传送到开发平台。或者是因为在某个开源软件的官方版本库中没有提交权限，需要将自己的改动以补丁文件的方式提供给官方。 关于补丁文件的格式，补丁的生成和应用在第3篇第20章“补丁文件交互”当中已经进行了介绍，使用的是git format-patch和git am命令，但这两个命令仅对Git库