GIT:在new/dirty/dev分支中提交对旧/安全分支的更改,而不检出或丢失未分段的数据

Question

在我开始开发实验之前,我创建了一个新的分支.我经常忘记(这不是问题),但现在我事先做了.
从那以后,我更新了3个文件.

• 在2中只是实验性的变化,我不想将其提交给安全分支.
• 在1中只是安全(次要)更改,我绝对想要安全分支.我很好地将这些最后的更改提交到新分支(但不是).

是否有可能 - 我确定是 - (快速)从我的(脏)工作目录中提交一些未经分级的,未提交的更改到一个旧的,安全的分支？

我唯一能想到的是切换分支(没有checkout),在1个文件中提交更改并切换回来,但我不知道切换回脏分支时会发生什么变化(他们还在那里吗？或者他们因为承诺而"消失"了吗？)......

我确信GIT有一些美丽的东西,但GIT有这么多,我找不到完全相同的东西.
(我一直在使用这个'手册'来寻求帮助, 但我不确定那里有同样的东西.如果是(并且你愿意扫描那个东西),请告诉我,所以我知道下一个时间看起来更难.)

谢谢!现在,我只是保留一张纸,方便更改'以后安装分支'.

Answer 1

无法使用git commit向备用分支添加提交.有一些方法可以使用低级"管道"命令来完成您所描述的操作,但这些命令形成的接口并非设计用于交互式使用¹.肯定有办法做你想做的事; 根据您的更改的细节和涉及的分支的内容,它可以非常简单.

简单案例:只需使用 git checkout

当切换分支,git的结帐将保留提交的修改或拒绝切换(除非你使用--force,--merge或--conflict).因此,只要您未提交的更改仅触摸HEAD(当前分支)和目标分支中相同的文件,git checkout将在切换分支时将这些更改保留在索引和/或工作树中.如果未提交的更改满足此条件,则可以执行以下操作:

git checkout safe-branch
git add -- files-with-safe-changes
git commit
git checkout -

^{您还可以使用git add --patch仅暂存和提交文件中的某些更改.}

在此之后,您的"安全变更"将成为"安全分支"的一部分; 切换回原始分支将"留下它们"(请记住,git checkout仅在切换分支时保留未提交的更改).

如果您的其他更改取决于"安全更改",您可能需要将"安全分支"合并到您的工作分支中(或者,根据您的工作流程,将您的工作分支重新绑定到"安全分支"的新提示上).为此,您必须存储未提交的更改(因为如果存在未提交的更改,则merge和rebase都将拒绝运行).

git stash save
git merge safe-branch
git stash pop --index

如果您的其他更改不依赖于"安全更改",那么您可能不应该为合并或rebase而烦恼.最终,您将这些分支合并在一起(例如,将它们合并到'qa'分支中进行预发布测试),但没有理由过早合并它们.

仍然很容易,但有点风险: git checkout -m

如果第一个git checkout抱怨"你有本地更改some?file; 没有切换分支.",这意味着您有未经修改的更改,some-file并且文件在'safe-branch'和您当前分支的提示中是不同的; 你需要一个不同的方法.

如果您确信更改将完全适用some?file于'safe-branch'中的版本,那么您可以使用-m/ --merge选项告诉git checkout尝试调整更改,以便它们适用于'safe中的文件-科'.如果无法完全合并,那么最终会出现合并冲突,并且可能很难恢复原始更改(这就是我称之为"冒险"的原因).

安全:git stash+git checkout -m

由于您实际上只想将更改的子集移回"安全分支",因此最好只关注这些更改.一种方法是使用git stash暂时保存当前更改,这样您就不必将它们全部拖回'safe-branch'(稍后将其中的一些/大部分拖回工作分支).

git stash save
git checkout stash -- files-with-save-changes
git checkout -m safe-branch
git commit
git checkout -
git stash pop --index

^{其他变化是可能的.您可以使用git checkout -p stash -- files仅挑选这些文件中的一些更改.如果索引中没有分阶段的更改,那么您可以先进行"安全更改",git add -- files(再次,可选-p),使用git stash save --keep-index,切换分支(使用合并),然后提交(即替换git checkout stash -- files预先安装的"安全更改" )改变"和" git stash --keep-index.}

在这种情况下,我认为git checkout -m是安全的,因为我们使用git stash来保存当前更改的副本; 如果三方合并尝试导致无望的混乱,那么你可以轻易放弃将"安全更改"置于"安全分支"并恢复工作的想法:切换回原始分支并弹出存储(git checkout -f - && git stash pop).

同样,如果您的其他更改取决于"安全更改",那么您将需要合并或重新绑定.您可以在弹出存储之前执行此操作(因为您需要一个干净的索引和工作树来执行合并/ rebase).

如果你不打算立即将你的工作分支与"安全分支"合并(或重新绑定),那么你可能想要在弹出存储后撤消"安全更改"("安全更改"是保存在原始存储中,您可能不希望最终提交在两个不同分支中从头开始进行相同更改的提交²).弹出存储后,使用git checkout -- files-with-safe-changes将这些文件还原为工作分支顶端的版本.

_{¹ "管道"界面设计用于脚本.在命令行上直接使用它们会很麻烦.早期版本的git commit(以及大多数其他Git命令)都是基于此接口的shell脚本.它们今天仍然可以编写为shell脚本,但C版本通常要快得多.提交备用分支所需的步骤是:
基于"安全分支"顶端的树设置备用索引,
使用"安全"更改更新索引(如果更改无法干净地应用,该怎么办？很高兴有一个工作树让用户解决冲突),
将索引写为树对象,
创建一个指向新树的新提交对象,并将当前提示"safe branch"作为其父级,
更新"安全分支"ref以指向新提交.}

_{² 在两个分支中进行"安全更改"没有任何技术上的错误,但通常最好确保每个更改仅来自一个地方.}

Answer 2

所以你的情况是

x--x--x (safe)
       \
        <a,b,c> (3 private evolutions in exp branch)

你想去

x--x--x--a (a committed only in safe banch)
       \
        b,c (b and c commited in exp branch)

你可以:

git add a
git commit -m        # in exp branch, gasp!
git stash save       # save the rest of the exp work in progress
git checkout master
git merge exp        # fast-forward merge

x--x--x--a (safe,exp)
          \
           [b,c] (stashed)

git branch -f exp HEAD~1  # reset branch exp to before 'a'
git checkout exp
git stash pop
git add -A
git commit -m "..."

x--x--x--a (a committed only in safe banch)
      \
        b,c (b and c commited in exp branch)