我要求主分支每个issue ID只有一个(可能很大的)提交。然而，为了确认小提交的最佳实践，我还需要为每个issue ID创建和保持多个小提交。
我已经找到了一个好的解决方案(我认为):
- 创建一个特性分支my-feature-branchfrommain。
- 对my-feature-branch进行多次小提交。
- Inmain:
git merge --squash my-feature-branch - main现在有了大的提交，自动带有一个提示小提交的消息，所以你可以随时"放大"。
- 保留my-feature-branch并停止工作
- 创建一个新的功能分支my-feature-branch-2等
但是，如果不需要多个特性分支就更好了。如果有一个额外的分支就好了，例如main-detailed。问题是，每当我git merge --squash main-detailed到master时，Git都会尝试合并main-detailed的完整历史，因为它不知道以前的merge --squash提交中已经合并了一些历史。是否仍然有可能以某种方式实现期望的工作流?
我将假设main(包含压缩的提交)是某种"官方的";视图中一定不能显示历史记录中的详细信息，并且该详细分支是"个人"的。分支，让你调查一个对开发人员更有用的历史记录。
我建议你保留以下历史记录:
0--------A-----------D <-- main
a--b--c--o--d--e--f--o <-- detailed
两个分支有一个共同的碱基0。你在分支detailed上开发。第一个特性包括提交a、b、c。准备好后，切换到main，然后
git merge --squash detailed
创建commitA。然后切换回detailed和
git merge main
这不会引入任何新的更改，因为此时两个分支的尖端必须相等。对包含提交d、e、f的特性重复此过程，以创建压缩合并提交D。
合并main到detailed的效果是，压缩合并不会考虑已经合并的特性提交。当您查看main的历史记录时，详细的提交是不可见的，但是当您查看detailed的历史记录时，您可以看到所有的提交，包括main中的提交。