关注

Py学习 » Git

Git合并更改是否应影响源分支?(为什么我丢了一些工作?)

Jason Clark • 5 年前 • 1320 次点击

我似乎丢失了一些值得编辑的文件,所以我正在努力找出我做错了什么。看起来Git合并对源分支和目标分支都有影响。我不担心找到丢失的编辑,只是修复我对Git的理解。

我有一个 develop 分支机构。我创造了一个 feature-x 分支,做了一些工作,并进行了一次影响8个文件的提交(称为提交“WIP”)。然后我切换回 发展 ,在其他功能上做了一些其他工作(自合并以来),今天我需要从 特性-X 进入之内 发展 :

git checkout develop
git merge feature-x --no-commit --no-ff

所以现在 发展 有我的 特性-X 顶部更改,未提交/未过期。我准备并提交了两个文件(称为提交“两个文件”),但我决定不准备将其余的文件提交给 发展 . 我想把它们留在里面 特性-X 但我觉得值得重新调整 特性-X 在电流上 发展 分支机构。在这一点上,我想 特性-X 仍应保持不变-合并只应更改 发展 . 所以我清除了合并中未提交的更改:

git reset --hard HEAD; git clean -f -d

尝试重新平衡 特性-X 发展:

git checkout feature-x
git rebase develop

我希望现在我的历史能显示我所有的年长者 发展 提交,然后新的“两个文件”提交,然后“WIP”提交来自 特性-X 在顶部重新固定。但我看到的只是“两个文件”…来自“WIP”提交的更改似乎已不复存在。

我哪里出了问题?我在签出后忘记检查提交日志 特性-X 就在重新平衡之前,但我必须假设“WIP”提交已经不存在了,因为它在重新平衡之后就不存在了。做了 merge --no-commit --no-ff 到上面 发展 也改变 特性-X ?

Python社区是高质量的Python/Django开发社区
本文地址：http://www.python88.com/topic/38007

1320 次点击

文章 [ 2 ] | 最新文章 5 年前

• 1 楼

gazdagergo 6 年前

我会这样做:

我意识到我需要最后(WIP)承诺的一部分 feature-x . 我结账去 特性-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 当我重新设置或合并我的 特性-X 分支与开发,因为Git将认识到这两个分支的变化完全相同。

• 2 楼

torek 6 年前

首先,我建议您在 Think Like (a) Git . 它们对于理解Git的工作方式至关重要。

至于发生了什么,我做了一个小仓库,尽我所能地重复了你的一些命令:

git checkout develop
git merge feature-x --no-commit --no-ff
因此,现在开发将我的特性X更改放在最前面,未提交/未提交。

不:你现在正在进行一次未完成的合并。这个 --no-commit 选项取消提交,将您留在该合并中。

$ git merge feature-x --no-commit --no-ff
Automatic merge went well; stopped before committing as requested

此外,Git 自动将所有成功合并的文件复制到临时区域。 集结区也被称为指数我倾向于用这个名字来称呼Moreholds 全部的 提交的文件。每次提交都是 每个文件 以便以后可以完全完整地提取。

$ 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 到上面 发展 也改变 feature-x ?

否:但是提交合并会更改 合并基础 未来的运营和变化 哪些承诺可以实现 来自不同的分支名称。这种影响 git rebase . 特别是,您在WIP提交时 特性-X 现在可从访问,因此包含在 发展 所以制作 特性-X 从…的尖端延伸 发展 不再需要了 特性-X 包含WIP提交的副本,因为它已经 在里面 这个 发展 分支机构。因此,REBASE不会费心复制提交:它将在 二者都 从现在开始。

登录后回复