我对git很新，只能自己工作，所以我不能使用它可以做的许多功能但是我遇到了一个过程，无论是我在考虑错误还是做某事错。
我有一个提交（init）的主分支。
我有一个180个提交的开发分支。
今天我终于准备将开发分支合并到主人，我做了一些阅读并发现了壁球。这似乎是有用的，因为我不会使用开发分支中的相同WIP提交来污染主分支。
所以我跑了
git checkout master
git merge --squash develop
git commit
从这里看，一切看起来都像我预期的那样，master有2次提交，develop仍有180次。在我脑海中，我现在再次查看develop并继续工作。我推到bitbucket并浏览了我的项目以查看此合并，并注意到以下内容：
1 commit(s) on master and not on develop
179 commit(s) on develop and not on master
这只是预期的行为，我应该忽略它，或者我做错了什么。
答案 0 :(得分：2)
这是预料之中的，因为git将所有提交合并到一个提交中，与开发分支中的提交相比，这将是一个不同的提交。将提交视为一组更改的容器，如果您更改了内容，则会有不同的内容。
您必须接受此方案，或者您可以通过在功能分支中工作来调整您的工作流程，例如： master - develop - feature-branch。
完成一项功能后，您可以从功能分支进行压缩合并，以开发和删除功能分支。现在，您可以在没有所有WIP提交的情况下进行从开发到主控的合并，例如当你发布新版本时。
答案 1 :(得分：0)
当您在Git中压缩提交时，它会将它们合并为一个提交。但是，如果要将来自多个提交的更改合并到新提交中，则需要合并。
在你的情况下，我认为你打算做的是合并没有＆＃34; fastforwarding＆＃34;。通过这种合并，你最终将拥有master（初始和合并）中的2次提交和dev中的180次提交。
代码将是（在dev中的最后一次提交之后）：
git checkout master
git merge dev --no-ff