我似乎丢失了一些值得编辑的文件，所以我试图找出我做错了什么。看起来好像git merge影响了源分支和目标分支。我不必担心会丢失丢失的编辑内容，而只是修复对git的理解。
我有一个develop分支。我创建了一个feature-x分支，做了一些工作，并进行了一次影响8个文件的提交（将提交称为“ WIP”）。然后我切换回develop，在其他功能上做了一些其他工作（由于合并），今天我需要从feature-x到develop中获取一些片段：
git checkout develop
git merge feature-x --no-commit --no-ff
因此，现在develop的{{1}}更改位于顶部，未提交/未暂存。我上演并提交了两个文件（称为“提交两个文件”），但是我决定不准备将其余文件提交给feature-x。我想将它们留在develop中，但认为值得将feature-x重新部署到当前的feature-x分支中。在这一点上，我认为develop应该保持不变-合并应该只更改了feature-x。因此，我从合并中清除了未提交的更改：
develop并尝试将git reset --hard HEAD; git clean -f -d
立足于开发：
feature-x我希望现在的历史记录可以显示我所有的旧git checkout feature-x
git rebase develop
提交，然后显示新的“两个文件”提交，然后再显示develop中的“ WIP”提交。但是我所看到的只是“两个文件” ...“ WIP”提交中的更改似乎已经消失了。
那我哪里出错了？我在重定基准之前就签出了feature-x之后，忘记了检查提交日志，但是我不得不假设“ WIP”提交已经消失了，因为它在重定基准之后就消失了。 feature-x上的merge --no-commit --no-ff是否也更改了develop？
答案 0 :(得分：1)
我将通过以下方式执行此操作：
我意识到我需要feature-x的最后一次（WIP）提交的一部分。我结帐到feature-x。
git checkout feature-x
我重置了最后一次提交：
git reset --soft HEAD~1
我撤消了所有任务，仅对两个文件进行了所需的更改（至少有可能在我的VSCode中仅对文件的选定部分进行了过渡）。之后，我提交：
git commit -m "Two files" // git will generate a commit with hash `a1b2c3d4`
然后我安排其余的工作并提交：
git add .
git commit -m "WIP rest"
现在，我可以在开发过程中随意挑选所需的更改：
git checkout develop
git cherry-pick a1b2c3d4
使用cherry-pick的优点是，以后在我将feature-x分支与development合并或合并时，它不会引起问题，因为git会认识到这在两个分支中完全相同。
答案 1 :(得分：1)
让我开始说，我建议您研究Think Like (a) Git中的概念。它们对于理解Git的工作方式至关重要。
关于发生的事情，好吧，我做了一个小的存储库，并尽可能地重复您的一些命令，只要您在这里告诉我们的内容即可。
git checkout develop git merge feature-x --no-commit --no-ff因此，development现在将我的功能-x更改放在最上面，未提交/未登台。
否：您现在处于未完成合并的中间。 --no-commit选项禁止提交，使您无法进行合并。
$ git merge feature-x --no-commit --no-ff
Automatic merge went well; stopped before committing as requested
此外，Git 自动将所有成功合并的文件复制到暂存区域。暂存区域（也称为 index ），我倾向于更多地使用该名称。 —保存 all 所有已提交的文件。每次提交都是每个文件的完整快照，以便以后可以完全完整地将其提取。
$ git status
On branch develop
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: README
new file: new.1
new file: new.2
如果您使用git reset（以其多种模式之一-我认为该命令执行了太多不同的事情，因此讨论起来可能会很棘手），则可以从以下其中一种复制文件提交将返回到暂存区域，以便某些文件的暂存区域版本与文件的develop版本匹配，或者根本不包含文件副本（如果文件是新的），而不包含结果一些合并动作。
我上演并提交了两个文件（调用“提交两个文件”）...
否，这时您只需完成合并即可。 Git现在知道两个分支上一系列提交的正确组合是此特定提交的结果。
请注意，git commit --only目前无法使用：
$ git commit --only README
fatal: cannot do a partial commit during a merge.
另一方面，git commit --include 可以，但这等效于先运行git add，然后运行git commit，以便提交合并。
$ git commit
这时，一个人的编辑器打开一个文本文件，内容为：
Merge branch 'feature-x' into develop
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
# .git/MERGE_HEAD
# and try again.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch develop
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
# modified: README
# new file: new.1
# new file: new.2
#
将此文件写出然后退出会产生：
[develop 2313673] Merge branch 'feature-x' into develop
我得出的结论是，要么您运行了一个未显示的命令（这可能很关键），要么是您提交了合并，这将解释您所看到的行为。特别是：
在
merge --no-commit --no-ff上的develop是否也更改了feature-x？
否：但是提交合并会更改将来操作的合并基础，并且会从各个分支名称中更改可访问哪些提交集。这会影响git rebase。特别是，您现在可以从feature-x到达并因此包含在develop中，因此您可以在feature-x上进行WIP提交，因此不再需要develop从feature-x的尖端扩展develop包含WIP提交的副本，因为它已经在 SELECT
WORDS.word_name as word1,
WORDS.word_name as word2,
from table WORDS, WORD_TYPES, POPULAR_WORDS
where WORDS.w_id = WORD_TYPES.w_id
and WORDS.w_id = POPULAR_WORDS.wi_id
ORDER BY WORDS.word_name
分支中了。因此Rebase不会费心去复制提交：从现在开始它将在两个分支中。