试图添加git-p<；文件名>；但是git什么都不做

我正在尝试使用，以便应用我所做的一项重大更改。我做了以下工作：

 1. git pull (before I started working)
 2. changed some code
 3. git diff > ~/my_diff
 4. git stash
 5. git pull
 6. git stash pop 

由于冲突，此操作失败，因此我尝试：

 7. cp ~/my_diff ./
 8. git add -p ~/my_diff

但我什么也得不到。。。该文件包含很多更改，但由于某些原因，它建议没有大块的补丁。有什么问题

---

这是git的准确响应：

Your branch is up-to-date with '...'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        my_diff

nothing added to commit but untracked files present (use "git add" to track)
.../trunk $ git add -p my_diff
    No changes.

---

所以您可以看到它是一个格式良好的diff文件

要应用my_diff，您应该使用git命令应用补丁，如下所示

---

git apply mydiff

拉之前不必“git diff”，只需隐藏即可。然后拉“藏起来”并修复冲突。Git不会从隐藏中删除您的更改，因此如果您的冲突修复失败，您可以重新开始。您应该在末尾手动清空您的存储空间（仅在冲突的情况下）

git add-p不读取补丁文件。相反，它接受一个已经在Git源代码控制下的文件，并将该文件的索引版本与该文件的工作树版本进行比较。不管有什么不同，这就是git add-p让您以交互方式修补索引的原因

因此，您需要将每个修改过的文件保存到某个地方，切换提交，将所有修改过的文件恢复到工作树中，然后运行

git add-p

（完全没有参数）。但这通常是错误的做法，因为它会失去其他人的改变

以下是我的建议，而不是这个顺序，以及原因：

git pull

（在[开始工作]之前）

将其拆分为

git fetch；git merge

，这样您就可以准确地知道git pull对您做了什么。（有人可能会对你说，但在

git-pull

的情况下，它倾向于对你而不是对你。我对git 1.5糟糕的旧时光的体验可能会在这里展示出来。：-

git-pull

在某些情况下会严重破坏存储库。）

实际上，我在这里使用了

git merge--ff only

，以确保没有发生任何异常情况。（我有一个别名，

git-mff

，它运行的是

git-merge--ff-only

。有时我会使用一些其他技巧，但现在已经足够了。）

更改了一些代码

保留此部分。：-）

git diff>~/my\u diff

别管这个了。相反，运行

git add

和

git commit

。如果在步骤2中做了很多更改，可以先创建一个新的分支名称：

git checkout -b mostly-ready  # or some more suitable name
git add -u         # or `.` or `-a` if you prefer
git status         # check for unexpected new files, or untracked files
                   # make any adjustments you like here
git commit
git checkout -     # go back to previous branch

git隐藏

这已不再需要。git stash所做的一切都是在无分支上进行提交；通过执行上述操作，或者更简单的

git提交

，您已经在某个更合适的分支上进行了提交

git pull

将其拆分为

git fetch；git merge

或者，如果您在分支本身而不是分支上进行了提交，

git fetch；git rebase

。（您可以运行

git pull--rebase

来执行fetch和rebase序列，但我认为最好将这两个步骤分开。）

git隐藏流行音乐

既然你没有藏品，这里就没什么可爆的了。如果您进行了适当的提交并使用了

git-rebase

，那么rebase将有合并冲突（如果存在的话），因为它会将提交向前传输。否则，您的提交就在您的分支上

基本就绪

，或者您所称的任何分支，现在您可以运行：

git cherry-pick -n mostly-ready

-n

告诉Git不要提交结果。这使您有机会查看它，如果愿意，可以使用

git add-p

。如果存在合并冲突，

-n

是多余的，因为Git无论如何都无法提交结果。请注意，这里有一个重要的警告：您的一些更改可能已经准备就绪

确切地说，这意味着什么 在这里，重要的是要记住，在Git中，每个文件都有三个副本。让我们举一个名为“代码> Read .txt < /COD>”的文件。三份副本为：

• HEAD:README.txt

  （试试

  git show HEAD:README.txt

  ）。这是文件的提交版本，特别是当前提交中的版本（aka

  HEAD

  aka

  @

  ）
  此副本已冻结为提交。在提交中，它是永久的（只要提交存在），并且是100%只读的。它以仅Git的压缩格式存储在内部，有时非常压缩。很少有其他项目能解决这个问题；它基本上是一种只使用Git的格式，因此您必须使用

  Git show

  或

  Git checkout

  来获取它

• README.txt

  。这是工作树版本
  这只是一个普通的文件。你可以用它做任何你喜欢的事。Git其实并不太在乎这个副本；Git只是把它放到你的工作树中，这样你就可以访问它并使用它

• ：0:README.txt

  。这是索引版本
  索引，也称为暂存区，有时也称为缓存，保存着Git确实关心的一个版本，但它是一种特殊的、压缩的、仅限Git的格式。此文件已准备好进行下一次提交，但与冻结的只读提交版本不同，您可以覆盖索引副本
  这就是git add所做的：

  git add README.txt

  用工作树版本

  README.txt

  覆盖索引版本

  ：0:README.txt

  。这是Git告诉您有准备提交的更改的时候。并不是说，

  README.txt

  突然出现在登台区：它一直都在那里。只是现在您在旧的

  ：0:README.txt

  之上复制了一个修改后的

  README.txt

  ，现在暂存区中的版本与ve不同

  git cherry-pick -n mostly-ready
  

  git reset README.txt
  

  git diff --cached
  

  git diff
  

  git status