尝试git add -p <file_name>，但是git什么都不做

时间：2018-09-13 11:58:28

标签： git git-commit git-add

我正在尝试使用this来应用我所做的重大更改。我做了以下事情：

 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.

这里是head -30 ~/my_diff：

diff --git a/trunk/files_transfer_mgmt/inc/files_transfer_mgmt.h b/trunk/files_transfer_mgmt/inc/files_transfer_mgmt.h
index 28907bd..f108931 100644
--- a/trunk/files_transfer_mgmt/inc/files_transfer_mgmt.h
+++ b/trunk/files_transfer_mgmt/inc/files_transfer_mgmt.h
@@ -13,6 +13,7 @@
 #include "iss_api.h"
 #include "rf_termserver.h"
 #include "rf_versions_util.h"
+#include "common_apis.h"

 #ifdef __cplusplus
        extern "C" {
@@ -23,23 +24,40 @@

 #define DEVICE_SFP             "/dev/sfp"

-#define        SECONDS_TO_USECONDS(seconds)    (seconds * 1000000)
+#define SECONDS_TO_USECONDS(seconds)   (seconds * 1000000)
+
+#define DEFAULT_FTPS_ERR_LOG "FTPS_error_log_tmp.txt"

 #ifdef __cplusplus
         }
 #endif /* __cplusplus */

 void SECURE_StartFileDownloadFromHere(void * data);
+void SECURE_ZT_entry_point(void * data);
 void SECURE_StartGenericFileTransferFromHere(void * data);
 void SECURE_getDownloadStatus(int argc, char *argv[],FILE *fin, FILE *fout,pedro_callback_func_args_t *pedro);

所以您可以看到它是格式正确的差异文件

2 个答案:

答案 0 :(得分：2)

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

因此，您不得不将每个修改后的文件保存在某个地方，切换提交，将所有修改后的文件恢复到您的工作树中，然后然后运行{{1 }}（完全没有参数）。但这通常是错误的方法-失去了每个人的其他变化。

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

  
      
  1. git add -p（在[开始工作之前]）
    2.   

将其拆分为git pull，以便您确切了解git fetch; git merge对您的作用。 （有人可能会为您说 ，但是在git pull的情况下，它倾向于是发给给您而不是 for 给您。我在Git 1.5的旧时的糟糕经历可能会在这里显示出来：:-) git pull在某些极端情况下曾经严重破坏了存储库。）

我实际上在这里使用git pull只是为了确保没有任何奇怪的事情发生。 （我的别名为git merge --ff-only，简称为git mff。有时我会使用其他一些技巧，但这已经足够了。）

  
      
  1. 更改了一些代码
    2.   

保留这一部分。 ：-）

  
      
  1. git merge --ff-only
    2.   

不要为此烦恼。而是运行git diff > ~/my_diff和git add。如果您在步骤2中进行了很多更改，则可以先创建一个新的分支名称：

git commit
  
      
  1. 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
    2.   

这不再是必需的。 git stash所做的只是在 no 分支上进行提交；通过执行上述操作或更简单的git stash，您可以在更合适的分支上进行提交。

  
      
  1. git commit
    2.   

将其拆分为git pull，或者，如果您是在分支本身而不是在侧分支上进行提交的，则将git fetch; git merge拆分。 （您可以运行git fetch; git rebase进行获取和重新设置序列，但是同样，我认为最好将两个步骤分开。）

  
      
  1. git pull --rebase
    2.   

由于您没有藏匿处，因此这里没有东西可弹出。如果您进行了提交并使用了git stash pop，则rebase将存在向前传输提交时发生的合并冲突（如果存在）。否则，您的提交将在分支git rebase或您所谓的分支上，现在可以运行：

mostly-ready

git cherry-pick -n mostly-ready 告诉Git 不提交结果。这使您有机会查看它并根据需要使用-n。如果存在合并冲突，则git add -p是多余的，因为Git仍然无法提交结果。请注意，有一个重要警告：您所做的更改中的一些已经发布。

上演的意思是

请务必记住，在Git中，每个文件都有三个副本。让我们以一个名为-n的文件为例。这三个副本是：

  • README.txt（尝试HEAD:README.txt）。这是文件的提交版本，特别是当前提交中的版本（也称为git show HEAD:README.txt或HEAD）。

    此副本被冻结为提交。在提交中，它是永久性的（好，只要提交存在），并且100％只读。它以仅Git的压缩格式在内部存储-有时非常压缩。几乎没有其他程序可以处理它；它基本上是仅支持Git的格式，因此必须使用@或git show来实现。

  • git checkout。这是工作树版本。

    这只是一个普通文件。您可以用它做任何您想做的事。 Git并不太在乎这个副本。 Git只是将其放入您的工作树中，以便您可以访问它并对其进行处理。

  • README.txt。这是 index 版本。

    该索引（也称为暂存区或有时称为 cache ）具有Git 关心的版本，但是采用特殊的，压缩的，仅Git格式。该文件已准备好进入您要进行的下一步提交-但与冻结的只读 committed 版本不同，您可以 覆盖索引副本。

    这就是:0:README.txt的作用：git add用工作树版本git add README.txt覆盖索引版本:0:README.txt。这是Git告诉您，有变更已提交提交。并不是README.txt突然出现在登台区域：一直存在。只是现在您将修改后的README.txt复制到旧的README.txt之上，现在暂存区域中的版本与冻结到{{1 }}提交。

因此，这里要记住的事情是您必须处理工作树文件：您可以编辑这些文件，并且随心所欲。但是一旦完成，就必须在索引版本的顶部复制工作树版本。某些Git命令（例如:0:README.txt）是通过使冻结的提交版本和索引版本相同来开始的。有些文件，例如HEAD，可以更改索引版本（通常同时也更改工作树版本）。使用git checkout会完全覆盖索引版本。使用git cherry-pick，可以用冻结的git add版本覆盖暂存版本：

git reset

表示将HEAD复制到git reset README.txt 上方，而完全不触及工作树HEAD:README.txt。

当您最终运行:0:README.txt时，这样做确实非常简单：它将所有索引版本冻结到一个新的提交中。它们已经处于正确的形式，位于索引/暂存区中。工作树中的文件并不重要。仅索引中的文件很重要！

两种非常有用的README.txt表单

运行：

git commit

针对每个文件将git diff（冻结）版本与索引版本进行比较，并向您显示差异。这是您将要进行的提交中的区别。

运行：

git diff --cached

将每个文件的索引（准备提交）版本与工作树版本进行比较，并向您显示差异。这是您可以进行的提交与HEAD 可以进行的提交有所不同。

运行：

git diff

为您运行这两个差异，然后为您显示不同的文件名。在git add和index之间不同的文件被暂存提交，而在索引和工作树之间不同的文件暂不暂存提交。

答案 1 :(得分：0)

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

git apply mydiff

相关问题
最新问题