相关疑难解决方法(0)

如果没有创建分支并在新分支上做一堆时髦的工作,是否有可能在提交到本地存储库后将单个提交分解为几个不同的提交？

我在过去一小时内改变了一些事情,并一步一步地提交了它们,但我刚刚意识到我忘了在一些提交之前添加一个已更改的文件.

日志看起来像这样:

GIT TidyUpRequests u:1 d:0> git log 
commit fc6734b6351f6c36a587dba6dbd9d5efa30c09ce 
Author: David Klein <> 
Date:   Tue Apr 27 09:43:55 2010 +0200

    The Main program now tests both Webservices at once

commit 8a2c6014c2b035e37aebd310a6393a1ecb39f463 
Author: David Klein <>
Date:   Tue Apr 27 09:43:27 2010 +0200

    ISBNDBQueryHandler now uses the XPath functions from XPath.fs too

commit 06a504e277fd98d97eed4dad22dfa5933d81451f 
Author: David Klein <> 
Date:   Tue Apr 27 09:30:34 2010 +0200

    AmazonQueryHandler now uses the XPath Helper functions defined in XPath.fs

commit a0865e28be35a3011d0b6091819ec32922dd2dd8 <--- changed file …

什么非交互式git命令实现从Before到After的变化？

之前:

A---B---C---D

后:

A---C'---B'---D'

在维护实时系统时,我发现有时需要对文件进行临时临时更改 - 更改日志记录级别,向脚本添加跟踪选项等.

当我这样做时,我的半自动机制用于查找未提交的更改和未合并的分支通常会显示误报:

• 如果我保留未提交的更改,或者只是暂停,那么我的检查程序脚本将repo标记为脏.
• 如果我将它们作为"临时更改提交"提交,则会将其标记为"远程分支之前的更改"
• 如果我在没有遥控器的新分支上提交它们,它们会被标记为"没有遥控器的分支".

通常情况下,所有这些都需要找到尚未合并的更改,但这也意味着"隐藏"临时更改的每种方式也会被阻止.

请注意,我不希望--assume-unchanged,因为同一个文件通常包含临时更改(我不想提醒)和永久更改(我这样做),并查看处理临时更改(不承诺)Git没有提出满足所有这些要求的建议.

使用Mercurial,我会考虑使用Mercurial Queues来获得我想要的东西.我会用我的临时更改创建一个补丁,然后如果我的分析实用程序找到一个补丁队列,它会弹出它们,执行分析然后再推回它们.这将有效地仅删除临时更改,仅对我认为不是临时的更改执行分析,然后重新应用这些更改.

任何更改工作目录的方法的问题在于这会影响实时系统的行为 - 例如,我们的日志记录系统每10秒左右检查一次日志记录配置的更新.

那么,我怎样才能最好地指出git某些变化是暂时的,不应该被提交和/或合并,而其他变化应该？

如何重写已经推送到私有远程的旧提交的消息？我想保留时间戳和标签.

我在这里找到了这个命令:

git filter-branch -f --msg-filter \
'sed "s/<old message>/<new message>/g"' -- --all

为了保持我添加的标签: --tag-name-filter cat

执行命令时git告诉我:msg过滤失败

我要更改的消息是合并消息"合并分支'发布/ ...'"这是问题吗？

关于StackOverflow上的"flattening merge"的问题很少,答案通常是"git rebase".这些答案虽然错过了一个关键点 - 提交顺序.

假设有一个分支A,其中包含6月1日和8月1日的提交,而分支B具有7月1日的提交(更新以恢复下面描述的用例:分支是完全独立的,没有共同的祖先,例如来自2个不同的存储库).将B合并到A中时,会有以下历史记录(每个git日志):

Merged branch 'B'
Aug 1
Jul 1
Jun 1

现在,我正在寻找的是获得相同结果的方法,但是没有合并提交(因此具有基础线性历史的顺序,是的,这意味着重新提交提交).git rebase在这里没有用,就像它一样,你会得到以下历史:

Jul 1
Aug 1
Jun 1

要么

Aug 1
Jun 1
Jul 1

换句话说,git rebase总是将一个分支堆叠在另一个分支之上,而我正在寻找解决方案,它将按作者的提交日期排序提交.

显然,对于简单的情况,可以通过使用git rebase -i手动后处理git rebase来实现所需的安排,但这对大型历史来说并不实用,所以我一直在寻找自动命令/脚本.

用例？如果A和B代表同一个项目的不同部分碰巧在不同的回购中,并且时间已经通过将它们合并在一起来纠正,那么很自然地希望线性历史以实际的开发顺序展开.

我正在尝试将许多提交压缩成一个,问题是我需要通过作者(名称或电子邮件)来做.

案子:

可以说我有一个名为feature-a的分支,在这个分支中我有许多作者的许多提交.如何将作者(例如电子邮件)的所有提交压缩到一个提交中.我想这样做能够将所有作者提交合并到master中.

这里有什么帮助？

提前致谢

我知道有两种方法可以更改 git 中的提交消息。

第一个是git amend，它仅适用于最新的提交。由于我希望能够直接更改较旧的提交消息，因此这不是我想要的。

第二个是交互式变基，例如本答案中描述的，它也可以更改旧提交的提交消息。程序是使用

git rebase -i HEAD~n

我必须手动计算n我的具体情况有多大，然后滚动浏览所有这些提交的列表并将一个提交从 更改为pick，reword最后键入新的提交消息并强制推送。

老实说，虽然这可行，但这样做非常复杂且乏味。所以我的问题是，是否有一种更易于使用的选项（可能以别名的形式），可以一步自动执行此过程？

理想情况下，我想要一个像这样的命令：

git reword <hash> -m "New commit message"

然后用力推动。这可能吗？

编辑：我想摆脱交互性，因为我想以编程方式自动化程序中的一些 git 命令。在此过程中必须手动与 git 交互，这违背了这种自动化的目的。

每当我想将最新的提交修复到第二个最新的提交时,我就会这样做

git rebase HEAD~2 -i
<replace pick with fixup on line 2>

有没有办法在自动脚本中执行此操作,而不受人为干扰？

我尝试过这个并不起作用:

git commit --fixup=HEAD