Git 如何合并两个分支而不丢失另一个分支上不包含的文件？

我目前正在从事一个具有不同功能的项目，我为每个功能创建了一个不同的分支

---

我的所有文件当前都在master中。但每次我创建一个新分支时，我都会删除所有文件，只保留这些分支上与功能相关的文件

我的问题是：如何将要素分支合并到主分支中，而不实际丢弃所有其他文件

e、 g:Master branch有login.html、menu.html和contact.html文件 功能分支仅具有Feature.html文件

在分支主控上，当我执行

git合并功能

所有文件都将从主分支中删除，并且只保留feature.html，但我希望所有文件都位于主分支中，包括feature.html

您不应该从新分支上的项目中删除文件。。。但无论如何，让我们假设无论出于何种原因，这都是必须的。如果我最终要合并master上的分支，那么我可能会做一些小技巧来避免出现这个问题。。。但这需要一些额外的工作。我会在新分支的第一次提交时删除这些文件，而在该修订版上我不会做任何其他事情。然后，当我想合并回master时，我不仅会合并，而且会在删除文件的地方进行cherry pick（或rebase）丢弃commit，然后合并rebase/cherry pick分支

让我们假设我从master创建feature1分支，并在那里进行了3次修订。。。比如：

git checkout -b feature1 master
git rm index.html blahblah.html # delete the files I don't want to keep on the branch
git commit -m "Removing the files I don't want"
# work
git commit -m "First real revision of feature 1"
# more work
git commit -m "Second revision of feature 1"

在这一点上，我准备合并到主。。。然后我不会仅仅合并feature1，因为这会删除文件，因为我在feature1的第一个修订版中就这样做了，对吗？。。。我会放弃第一次修订，然后合并到master中，这可以相对容易地完成

git checkout --detach master # go back to master
git cherry-pick feature1~2..feature1 # only cherry-pick the last 2 revisions
git checkout master # go back to master again
git merge --no-ff HEAD@{1} -m "Merging feature 1" # merge rebased branch

这样就可以了。但我认为你无论如何都不应该删除这些文件。

你不应该从新分支的项目中删除这些文件。。。但无论如何，让我们假设无论出于何种原因，这都是必须的。如果我最终要合并master上的分支，那么我可能会做一些小技巧来避免出现这个问题。。。但这需要一些额外的工作。我会在新分支的第一次提交时删除这些文件，而在该修订版上我不会做任何其他事情。然后，当我想合并回master时，我不仅会合并，而且会在删除文件的地方进行cherry pick（或rebase）丢弃commit，然后合并rebase/cherry pick分支

让我们假设我从master创建feature1分支，并在那里进行了3次修订。。。比如：

git checkout -b feature1 master
git rm index.html blahblah.html # delete the files I don't want to keep on the branch
git commit -m "Removing the files I don't want"
# work
git commit -m "First real revision of feature 1"
# more work
git commit -m "Second revision of feature 1"

在这一点上，我准备合并到主。。。然后我不会仅仅合并feature1，因为这会删除文件，因为我在feature1的第一个修订版中就这样做了，对吗？。。。我会放弃第一次修订，然后合并到master中，这可以相对容易地完成

git checkout --detach master # go back to master
git cherry-pick feature1~2..feature1 # only cherry-pick the last 2 revisions
git checkout master # go back to master again
git merge --no-ff HEAD@{1} -m "Merging feature 1" # merge rebased branch

---

这样就可以了。但是我认为你无论如何都不应该删除这些文件。

“但是每次我创建一个新分支时，我都会删除所有文件，只保留这些分支上与功能相关的文件”出于好奇：为什么？你可以只做一个

git合并--不提交
，然后在提交之前将删除的文件从坟墓中取回，然后您可以进行
git合并--继续
。。。但我想知道：“如果最终合并到master中，那么为什么首先要删除这些文件，然后你就会面临这个问题？”有很多不同的功能，我不希望每次创建一个新的分支时都将整个项目复制到分支中！我只想将功能相关的文件保存在各自的分支中。@RodolfoRondon这似乎是一个误解。Git的结构就是这样，对象不会被复制。分支只是一个指针。如果你愿意的话，在回购协议中创建1000个分支，你会没事的。我想你误解了git的工作原理。创建新分支时，不会将文件复制到其中。相反，分支是对提交的一个非常轻量级的引用。提交只是自上次提交以来更改的记录。正如其他人所说，除非你真的想从整个项目中删除文件，否则你不应该删除这些文件。“但每次我创建一个新分支，我都会删除所有文件，只保留这些分支上与功能相关的文件”出于好奇：为什么？你可以只做一个
git合并--no commit
，然后在提交之前将删除的文件从坟墓中取回，然后您可以进行
git合并--继续
。。。但我想知道：“如果最终合并到master中，那么为什么首先要删除这些文件，然后你就会面临这个问题？”有很多不同的功能，我不希望每次创建一个新的分支时都将整个项目复制到分支中！我只想将功能相关的文件保存在各自的分支中。@RodolfoRondon这似乎是一个误解。Git的结构就是这样，对象不会被复制。分支只是一个指针。如果你愿意的话，在回购协议中创建1000个分支，你会没事的。我想你误解了git的工作原理。创建新分支时，不会将文件复制到其中。相反，分支是对提交的一个非常轻量级的引用。提交只是自上次提交以来更改的记录。正如其他人所说，除非你真的想从整个项目中删除文件，否则你不应该删除这些文件。即使我最喜欢的部分是，但我认为你无论如何都不应该删除这些文件，我还是要向你的直截了当和务实的决定致敬，实际上，我提出了一些比手工解决某个问题更具建设性的建议（就像我在某种程度上不幸地做的那样，即使我坚持我对提交的评论）。投票结果被否决。即使我喜欢的部分