Question

我有一个主分支，有一些东西，让我们说文件自述文件。我还有一个dev分支，master的子代，还有一些额外的文件，比方说文件README2。我做了以下事情：

class User < ApplicationRecord
  has_many :orgs_users
  has_many :orgs, through: :orgs_users
end

class Org < ApplicationRecord
  has_many :orgs_users
  has_many :users, through: :orgs_users

end

class OrgsUsers < ApplicationRecord
  belongs_to :org
  belongs_to :user

  after_create :send_approved_listing_email
  def send_approved_listing_email
    OrgMailer.org_approved(user, org).deliver_now if org.approved === true
  end
end

从master获取

并将文件README2合并为master。现在我将其删除：

git merge dev

现在当我再次合并dev时，我预计我会将README2文件合并到master中，因为它不再在master中了。但Git报告称没有任何变化，也没有任何合并。这实际上适合我，但我不明白这是怎么回事，因为此时分支dev显然有README2文件，而master则没有。

Answer 1

你误解了git merge的作用。它在提交树级别工作，而不是在单个文件级别。

我们假设您从这里开始，在两个分支上有两个提交A和B：

master --- A      # this has *no* README2 file

dev ------ B      # this has README2

然后您将dev分支合并到master。

master --- A ----+--- C
                /
dev ------ B --/

这将在主分支中创建新的合并提交（C）。 C包含其父母的历史A和B。这是将README2带入master分支的地方。

稍后，您从README2分支中删除了master。此文件删除将在D分支上生成新的提交（master）。

master --- A ----+--- C --- D
                /
dev ------ B --/

此新提交D包含master和dev的历史记录（由于C合并），以及您删除文件{{1}的事实}。我们假设您已对README2（下面提交dev）进行了更改，但它不涉及文件E。

README2

现在您再次将master --- A ----+--- C --- D / dev ------ B --+--- E合并到母版。

dev

您有一个新的合并提交master --- A ----+--- C --- D --+-- F / / dev ------ B --+--- E --------/，其中包含F和D的历史记录。主分支没有再次返回文件E，因为该文件已在README2（master）中删除，而新D提交{{1} }不包含dev的更新。

此时，如果修改E分支上的文件README2，然后尝试将其合并回README2，则最终会出现合并冲突。它看起来像这样。

dev

正如文中所说，两国之间存在冲突。在一个分支中，文件已被修改，但在另一个分支中已被删除。不确定接受哪一个，git放弃并要求你告诉它下一步该做什么。

Answer 2

这是因为通过从git跟踪系统中删除README2文件，它将忽略您将来可能对其进行的任何更改，这可能还涉及包含该文件的合并。如果您制作log，您可能会将文件视为未跟踪的文件。

我希望这有用，如果你想在该提交中实际删除文件而不是执行git status你可以简单地删除文件，git会将其注册为文件删除而不是unfrocking命令

Git merge第二次不合并文件

2 个答案: