合并GIT分支而不提交日志

Question

目前,当我使用GIT时,我为每个作业创建一个分支,并在完成之前进行各种提交.然后我与我的主分支合并并向上游推送.我可能在任何时候都有几个分支机构,并且在工作中间随着事情的发生而轻弹.

但是大多数这些提交只是保存点,即在宏观方案中并不重要.因此,当我合并分支时,如果分支日志没有与主日志合并,我会喜欢它.

有没有办法合并下面提交g的日志消息(而不是提交c或e)？

a [master] 
|
b (create branch 'job')
|\
| \
|  c 
|  |
d  e
|  |
f  g (next step is to merge 'job' branch with 'master')

Answer 1

我认为merge --squash在我使用"每个功能分支"方法时非常有用.我在临时分支中的提交历史是完全垃圾,绝对没有意义.而且我真的希望再也看不到这个历史,而不仅仅是为了能够跳过它.

当提交进行代码审查时,重要的是不要创建额外的提交.

答案是"merge --squash",这就是OP所寻求的.所有其他的词都被添加来解释为什么"merge --squash"并不像许多人想的那样总是"邪恶". (4认同)

Answer 2

有,但这是无稽之谈.你为什么要那样做？你将失去所有的分支历史和信息.

您可以使用g的提交消息进行合并提交,然后使用该--first-parent选项浏览历史记录.

如果你真的想从你的分支机构使用中丢失历史记录git merge --squash,我不推荐它

编辑

万一你不开心,因为你不认为你的历史很干净,你可以使用git的rebase功能:

您可以追溯编辑旧的并从现有分支创建新提交(实际上重写它).它允许您重写提交消息,拆分提交,压缩提交到单个提交,重新提交提交等.

你应该只在你没有发布你的分支时使用变基(即它只是一个私有分支),因为它会给其他开发人员带来麻烦,以后可能会导致合并问题,如果有人继续处理旧的(在重新定位之前)分支.

我认为merge --squash是完全合理的,事实上它是我用于OP解释的相同情况的:当你本地分支上的大多数提交都是"保存点"而没有什么需要共享的特殊情况. (6认同)
如果您保留完成工作的分支，您就不会丢失提交历史记录。回到中间某个地方的先前提交并成功编译。 (3认同)
*“有，但这是无稽之谈......”* - 为什么你想要在开发分支上出现的“修复内存错误”之类的消息出现在 Master 中，而 Master 从未遇到过它？不准确的日志是审计和 C&A 的噩梦。 (3认同)
@Adam：我完全同意 knittl；你不应该使用`merge --squash`，你应该只使用`log --first-parent` 来避免*查看*合并的提交。如果你想先清理它，`git rebase -i` (`--interactive`) 确实是要走的路 - 我想你会发现它非常直观。您可以阅读文档，但是第一次尝试时（例如`git rebase -i <commit-g>^ job`），应该很清楚您可以做什么。只是不要在已发布的分支上使用它！ (2认同)
`--squash` 是好是坏 - 取决于团队工作流程。当使用“功能分支”方法时，详细的历史记录保存在特定的分支中，而“master”只跟踪合并历史记录。 (2认同)