之前我已经通过创建克隆并在克隆中执行rebase来完成此操作,但我怀疑我可以在单独的分支上安全地执行此操作.
我有一个功能分支feat-x,大约有25个提交.我想(安全地)将其中的几个压在一起.
(我说"安全",因为前几次我被压扁了,我没有把它弄好 - 但是正在克隆中工作,所以只是把它扔掉,直到我弄清楚了正确的咒语.)
什么序列的命令会给我feat-x-exp一个副本,feat-x所以我可以尝试挤压而不会打扰feat-x？
关于如何使用任何建议RebaseCommand,MergeCommand或JGit到壁球提交任何其他命令？我找不到很多例子,文档也没什么帮助.
一个简单的例子
我想压制下面的树:
A-----B------C------D------E------F------G------H
进入这一个:
A----Z-----H
凡Z被压扁提交的B,C,D,E,F,和G.
任何建议和有用的资源表示赞赏.
Django文档说，我们可以在压缩迁移后删除它们：
您应该进行此迁移，但将旧迁移保留在原位置；新的迁移将用于新安装。一旦确定代码库的所有实例都应用了压缩的迁移，就可以删除它们。
在这里，删除是否意味着仅删除迁移文件或django_migrations表中的条目？
这里是一些背景：我只有开发机器，所以只有一个代码库。压缩一些已经应用的迁移后，我删除了文件和数据库条目。通过进行迁移测试是否可以，它没有找到任何东西。因此，一切看起来都不错。第二天，我不得不进行一些更改，并进行了迁移。当我尝试迁移时，它也尝试应用压缩的迁移（在压缩之前已部分应用）。因此，我不得不返回并在django_migrations表中重新创建条目。因此，似乎我不得不保留数据库条目。我试图确保在再次弄乱任何东西之前，先弄清楚为什么它看起来不错，然后再尝试应用压缩后的迁移。
在Git中，我可以使用交互式的基础来重写历史记录，这很棒，因为在我的功能分支中，我探索了不同的重构和完成方式时，使用部分有效的代码进行了大量提交。
在将分支重新合并或合并到master之前，我想将很多提交压缩在一起。
一些按从上到下的顺序排列提交
1. Initial commit on feature branch "Automatic coffee maker UI"
2. Add hot chocolate as product
3. Add tea as product. Products are now generic
4. Create in memory data store for adapter tests
5. Cry because I can't get entity framework to create a composite key. Integration tests broken.
6. Implemented composite key!!
7. All tests green and feature done!
假设我要保留提交3、4和7。
使用变基我想“压扁”提交
理想情况下，我会在交互式基础中执行
1. squash
2. squash
3. pick (contains the work …commit b0e5db36ed68d4562275adeb08001b1316a4da52
Merge: ea38baa 8220bb1
commit ea38baa3f46a48722987b8dd3892d2b8d81c4d1a
在这种情况下，我如何压缩这两个提交
我在用
git rebase -i HEAD~2
但这不起作用，因为它删除了合并提交并且不可用于挤压
我想在脚本中执行以下操作:
git merge --squash someBranch
git push
问题是合并不会提交.所以在推动之前我必须承诺.此合并创建的默认提交消息就足够了.所以我的问题是:
我可以自动生成提交进行合并吗？
或者我可以在脚本中添加一个命令来执行接受默认消息的提交吗？
谢谢!
假设我的回购中有以下历史记录:
git log --oneline
<3rd sha1> Third commit.
<2nd sha1> Second commit.
<1st sha1> First commit.
如何将第三个提交压缩到第一个提交而不保持第二个提交？
我有一个分支git存储库,有~4000次提交.我想根据创建日期对提交进行分组.例如,鉴于以下提交:
abcd 2013-4-1 12:10
abce 2013-4-1 13:27
...
cdef 2013-4-1 18:16
cdeg 2013-4-2 09:23
...
gade 2013-4-2 18:20
fdeg 2013-4-3 09:42
...
我想获得一个提交历史,例如all abcd- cdef提交合并到一个提交,所有cdeg-gade合并为一个,依此类推.我试着用rebase作为
git reset --hard cdef
git rebase -i abcd
我无法压缩所有提交,得到了下面的错误消息.
"Cannot 'squash' without a previous commit"
我试图一次压制一个提交,但它确实有效,但它花了很长时间才显然不可行.
如何根据创建日期合并提交？
经过多次努力,我无法弄明白.我有两个地方分支机构,master和tests.我有两个相应的远程分支,具有相同的仓库origin/master,origin/tests.我有另一个远程分支public/master.我有一些推送本地master和远程的提交历史记录origin/master.现在,我想压缩所有提交origin/master并推入远程分支public/master.我无法弄清楚该怎么做.
我试过rebase在新的本地分支上做,但它没有用.
这看起来应该是一个简单的问题，但我整个早上都在寻找答案，但我就是找不到令我满意的答案。我能找到的最接近的东西是这个问题，Git merge squashrepeated，但这个问题是 11 年前的问题，所以希望“除非你创建临时分支，否则你根本无法做到这一点”的共识已经改变。
我正在从事一个长期项目，我基本上是唯一的贡献者。理想情况下，我希望有一个长期持续的development分支，我可以继续一点一点地修补和工作，并master在我达到稳定的可发布状态时定期对分支进行压缩合并。我不想让完整的提交历史记录可用/可见master，因为我希望能够轻松地向后浏览稳定的官方版本的历史记录。但是，我确实希望完整的提交历史记录可以在某个地方可用，以便它变得相关。
问题是，如果我尝试以直觉上认为应该有效的方式做到这一点，那就行不通。南瓜合并提交创建了一个与master中的任何内容都不匹配的提交development，因此下次我尝试执行南瓜合并时，它会说存在冲突，我需要从合并master到development...并且当我越来越多地重复这个过程，这个问题不断增长，我有六个提交在两个分支之间来回跳动，这些提交实际上并没有更改任何文件，但我似乎无法摆脱。
我想要制作的图形看起来像这样，如果这有意义的话：
B-------------------G-----------J master
/ / /
a---b---c---d---e---f---g---h---i---j development
到目前为止我一直在使用的解决方案非常丑陋：我使用版本号创建一个新分支，例如development_601，然后当我再次稳定时，我从该分支向 master 发出拉取请求，并压缩合并提交，然后我在挤压合并后创建另一个新development_602分支master。development_601被封存。这看起来很混乱、烦人，而且是错误的，特别是因为 Git 似乎暗示我应该在合并拉取请求后删除我的分支，但就像我说的，我想在某个地方记录我完整的混乱历史，我只是不这样做不希望它（轻易）从外部可见。
我一直在使用 Github Desktop 应用程序和 Github 网站；我一直试图避免将控制台命令放入我的工作流程中。
这是一种奇怪的行为吗？development我觉得“拥有一个带有master/分支的长期release分支，定期但不完全地反映它”是一种非常常见的系统，但不知何故，我找不到任何地方可以解释如何实现它。