当我开始使用git时，我的工作流基于Gitflow模型：http://nvie.com/posts/a-successful-git-branching-model/。我认为主要的想法是保持对适当分支的承诺;所以例如主分支只有从开发分支合并的提交...即标签... 0.1。 0.2。图中1.0。我不完全理解git是如何工作的，或者这个工作流是如何运作的，但这就是我的想法，特别是因为该页面上的图形只显示了主分支上的这些提交，而不是所有开发工具。
我将我的回购推送到Bitbucket，当我在开发分支工作时，一切顺利，但是当我完成开发时;并且推高了主分支我发现Bitbucket中的主分支现在包含我在开发分支上所做的所有提交，而我认为我只会包含最后一次提交（我合并的那个）。有人可以解释为什么这个，以及这是否是预期的行为，如果不是我可以做什么来使我的工作流程与上述模型一致。我使用Smartgit。
答案 0 :(得分：3)
您的分支模型似乎需要在每次合并时指定--no-ff，强制记账条目甚至是空合并 - 例如在您的图形中，您将从修补程序合并到0.2，这会将一个提交到主分支，实际上并没有与git merge --no-ff hotfixes进行任何合并。对于具有非git感知管理要求的项目，这是一种很好的方法。 VonC answered用于您在某处跳过该模型的--no-ff要求的情况。
对于您确实遵循模型并且不期望push表现得如此的情况：如果您在具有图形历史记录的仓库中检出1.0的主数据并推送到远程主分支当推送完成时，遥控器将提交M2，M4，M5，Y1-6，G1-4，R1和C1-3（根据颜色和垂直顺序标记其提交），远程主分支将参考所有这一切。
要理解的是，提交历史很重要，但引用名称不是，至少不是“资本 - I”重要。 git push
使用本地引用更新远程引用，同时发送完成给定引用所必需的对象。
通常，如果您的仓库是项目主要开发项目的一部分，那么您将跟踪一些“中央”仓库的ref名称。 Git的默认克隆为那些设置本地遥控器/ origin / *分支;但是其他的设置并不常见 - 如果你有一个repo，你在某个项目的v2.1上工作，你可能会认为其他repo的release-v2.1分支是你的repo的'master'分支。
如果您只想推送提交的结果而不推送其历史记录，则必须进行具有结果但没有该历史记录的新提交。其他dvcs是由那些以不同程度的反感来对待建筑历史的人建造的; git认为这样的选择不是它的任何业务：它提供（它）工具来实现你想象的任何模型。 git cherry-pick将通过将命名提交与其第一个父项进行区分，然后将该diff应用于当前头，并使用樱桃选择的提交消息来进行新提交。 Vanilla git rebase选择了一系列提交。我认为你期望的行为是git merge --squash; git commit所做的：在提交的历史中应用差异并忘记它们的来源。如果您这样做，其他任何地方的提交都不会出现在您的分支历史记录中。这绝对不是你的图形试图传达的模型。
答案 1 :(得分：2)
将development分支合并到master时，您可能会进行快进合并。
与git merge --no-ff相反，即使合并解析为快进，“（man page）”也会创建合并提交。
这意味着master HEAD只需移至dev HEAD，引用所有dev次提交。
答案 2 :(得分：1)
请按照以下步骤操作。也许你会自己找到答案。
确保您当前正在处理正确的分支
git branch -a //Shows you all the branches
git checkout {branch_name} //Make sure you checkout the correct branch
确保您的日志中有正确的提交
git log --oneline -6 // Show last 6 commits on this branch