合并后 Git 主分支根本没有新文件

Git master branch simply does not have new files after merge

提问by AJcodez

Suppose I have 2 branches, masterand other.

假设我有 2 个分支，master并且other.

I go in the otherbranch, add 2 files, commit and push.

我进入other分支，添加 2 个文件，提交和推送。

Now I go into the masterbranch, add files to a different directory, and commit them. Then I merge other.

现在我进入master分支，将文件添加到不同的目录，并提交它们。然后我合并other。

The problem is that the files I added in otherare not showing up. Git says it is up-to-date, but its not! Files are missing.

问题是我添加的文件other没有显示出来。Git 说它是最新的，但它不是！文件丢失。

How can I force masterto add the files in otheror somehow manually add them?

如何强制master添加文件other或以某种方式手动添加它们？

Edit for Karl:

为卡尔编辑：

I did the following to the best of my knowledge, although the changes that are not showing up are several weeks old. I just realized they weren't there today.

我尽我所知做了以下事情，虽然没有出现的变化已经有几个星期了。我才意识到他们今天不在那里。

$ git branch
*other
master
$ git add .
$ git commit -m 'cool new features'
$ git push origin other
$ git checkout master
$ git merge other
$ git add .
$ git commit -m 'merged cool new features from other'
$ git push origin master

I go on Github, and the files aren't there. Other files were committed and show up, but two folders do not have matching content. The files exist in otherbut not in master. To clarify, the files were not new. But I thought that merging would at least copy files to masterif they dont exist!

我去 Github 上，文件不在那里。其他文件已提交并显示，但两个文件夹没有匹配的内容。文件存在于other但不存在于master. 澄清一下，这些文件不是新的。但我认为master如果文件不存在，合并至少会将文件复制到！

采纳答案by Karl Bielefeldt

Like this:

像这样：

karl@Bielefeldt-Server:~/stackoverflow$ git init .
Initialized empty Git repository in /home/karl/stackoverflow/.git/
karl@Bielefeldt-Server:~/stackoverflow$ touch common_file_a
karl@Bielefeldt-Server:~/stackoverflow$ touch common_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git add .
karl@Bielefeldt-Server:~/stackoverflow$ git commit -m "commit common files"
[master (root-commit) 89a5cd0] commit common files
 0 files changed
 create mode 100644 common_file_a
 create mode 100644 common_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git checkout -b other
Switched to a new branch 'other'
karl@Bielefeldt-Server:~/stackoverflow$ mkdir other
karl@Bielefeldt-Server:~/stackoverflow$ touch other/other_file_a
karl@Bielefeldt-Server:~/stackoverflow$ touch other/other_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git add .
karl@Bielefeldt-Server:~/stackoverflow$ git commit -m "commit other files"
[other 9c7409c] commit other files
 0 files changed
 create mode 100644 other/other_file_a
 create mode 100644 other/other_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git checkout master
Switched to branch 'master'
karl@Bielefeldt-Server:~/stackoverflow$ touch master_file_a
karl@Bielefeldt-Server:~/stackoverflow$ touch master_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git add .
karl@Bielefeldt-Server:~/stackoverflow$ git commit -m "commit master files"
[master 3558768] commit master files
 0 files changed
 create mode 100644 master_file_a
 create mode 100644 master_file_b
karl@Bielefeldt-Server:~/stackoverflow$ ls
common_file_a  common_file_b  master_file_a  master_file_b
karl@Bielefeldt-Server:~/stackoverflow$ git merge other
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 other/other_file_a
 create mode 100644 other/other_file_b
karl@Bielefeldt-Server:~/stackoverflow$ ls
common_file_a  common_file_b  master_file_a  master_file_b  other
karl@Bielefeldt-Server:~/stackoverflow$ ls other
other_file_a  other_file_b

If you're getting different results, you're either missing a step, putting an extra step somewhere, or you're getting some sort of error you're not telling us about, like a merge conflict. We have no way of knowing why something so basic isn't working for you unless you post the exactcommands and output you're getting, like I did above.

如果你得到不同的结果，你要么错过了一个步骤，在某处放置了一个额外的步骤，要么你得到了某种你没有告诉我们的错误，比如合并冲突。我们无法知道为什么这么基本的东西对你不起作用，除非你像我上面那样发布你得到的确切命令和输出。

回答by user2845840

It's a little late, but for other users who find this question, I will describe a situation where the problem observed by AJcodez will occur. If you do a git checkout master; git merge other, during which or after which you delete some of the new files in master(and possibly forget about that fact) and later do a git checkout master; git merge otheragain, then the "new" files will not reappear in master, because they are not new. Merge only cares about changes relative to the merge-base, which is the youngest commit reachable via both branches. During your second merge, the merge-base is not the same as during your first merge, the merge-base during the second merge in the described scenario is the commit that was the tip of otherduring the first merge. If otherdidn't change the new files since then, then the deletion in masteris the most current change and therefore deletion of the new files will be the state after the second merge.

有点晚了，但是对于其他发现这个问题的用户，我将描述一个AJcodez观察到的问题会发生的情况。如果您执行 a git checkout master; git merge other，在此期间或之后您删除了master（并且可能忘记了该事实）中的一些新文件git checkout master; git merge other，然后再次执行 a ，则“新”文件将不会重新出现在 中master，因为它们不是新文件。Merge 只关心相对于合并基的更改，它是通过两个分支可到达的最年轻的提交。在您的第二次合并期间，合并基础与您第一次合并期间不同，所描述场景中第二次合并期间的合并基础是other第一次合并期间作为提示的提交。如果other此后没有更改新文件，则删除master是最新的更改，因此删除新文件将是第二次合并后的状态。

If that seems inconvenient, you can get around it by creating a temporary branch (let's call it merge_branch), merging otherinto it using --squash, committing, merging it into masterand deleting the temporary branch. It's probably not the ideal solution (e.g. already resolved merge conflicts might have to be resolved again), but then again the original situation is probably already the result of a mistake. Here is what I mean in code:

如果这看起来不方便，您可以通过创建一个临时分支（我们称之为merge_branch）、使用 合并other到它--squash、提交、合并到master和删除临时分支来解决它。这可能不是理想的解决方案（例如，已经解决的合并冲突可能必须再次解决），但是原来的情况可能已经是错误的结果。这是我在代码中的意思：

git log other # find the commit where 'other' originally branched off
git checkout -b merge_branch COMMIT_ID # go there & create branch
# without '--squash', the following merge would simply be a fast-forward
# merge and wouldn't solve our problem, because 'merge_branch' would then
# point to the same commit as 'other' and so the later merge into
# 'master' would produce the same unsatisfactory result.
git merge --squash other # does not create a new commit by itself
git commit # better add an explanation for what you did and why
# 'merge_branch' now contains everything you did in 'other' since it
# branched off from 'master', but squashed into a single new commit
git checkout master
git merge merge_branch
git branch --delete merge_branch

回答by bilbohhh

I solved this problem by creating empty file with the same name at master branch:

我通过在 master 分支创建同名的空文件解决了这个问题：

Suppose, the branch othercontains a new file newfile.txt that was not merged somehow to master.

假设分支other包含一个新文件 newfile.txt ，该文件未以某种方式合并到master.

git checkout master
touch newfile.txt
git add newfile.txt
git commit -m "create newfile.txt"
git merge other

It is kind of dirty, but works.

它有点脏，但有效。

回答by Pipo

Happend to me that only doing a

发生在我身上，只做一个

git merge other

is not enough. I had to pull changes from the otherbranch before mergingwith

是不足够的。我不得不从拉变化other分支合并前与

git checkout other
git pull
git checkout first

and then I was able to

然后我能够

git merge other