当我开始使用 git 时，我的工作流程基于 Gitflow 模型：http ://nvie.com/posts/a-successful-git-branching-model/ 。我认为主要想法是保持对适当分支的提交；因此，例如，主分支将只有从开发分支合并的提交......即标签...... 0.1。0.2。1.0 在图中。我不完全理解 git 是如何工作的，或者这个工作流程是如何运作的，但这就是我的想法，特别是因为该页面上的图形只显示了 master 分支上的这几个提交，而不是所有的开发提交。
我将我的 repo 推送到 Bitbucket，当我在开发分支工作时一切顺利，但是当我完成开发时；然后向上推主分支，我发现 Bitbucket 中的主分支现在包含我在开发分支上所做的所有提交，而我认为我只会包含最后一个提交（我合并的那个）。有人可以解释为什么会这样，这是否是预期的行为，如果不是，我可以做些什么来让我的工作流程与上面的模型保持一致。我使用 Smartgit。
Your branching model seems to require specifying --no-ff on every merge, forcing bookkeeping entries even for empty merges -- for example in your graphic you'd do the merge from hotfixes to 0.2, which gets that one commit onto the master branch and doesn't actually do any merging, with git merge --no-ff hotfixes. On projects with un-git-aware administrative requirements that's a good way to do it. VonC answered for the case where you skipped that model's --no-ff requirement somewhere.
For the case where you did follow your model and just weren't expecting push to behave as it does: if you checkout master as of 1.0 in a repo with your graphic's history and push to the remote's master branch, when the push completes the remote will have commits M2,M4,M5,Y1-6,G1-4,R1, and C1-3 (labeling its commits according to their color and vertical sequence), and the remote master branch will refer to all of that.
The thing to understand is that commit histories are important, but ref names are not, at least not "capital-I" important. git push
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
Usually, if your repo is part of a project's primary development you're tracking some "central" repo's ref names. Git's default clone sets up local remotes/origin/* branches for those; but other setups aren't at all unusual — if you've got a repo where you're working on v2.1 of some project, you might regard some other repo's release-v2.1 branch as your repo's 'master' branch.
If you want to push only the results of a commit, without pushing its history, you have to make a new commit that has the results but doesn't have that history. Other dvcs's have been built by people who regard constructing histories this way with varying degrees of repugnance; git sees choices like that as none of its business: it provides (it is) tools that implement any model you care to imagine. git cherry-pick will make a new commit by diffing the named commit against its first parent and then applying that diff to the current head, with the cherry-picked commit's message. Vanilla git rebase picks an entire sequence of commits like that. The behavior I think you were expecting is what git merge --squash; git commit does: apply the diffs in a commit's history and forget where they came from. If you do that, no commit from anywhere else will ever appear on your branch's history. That's definitely not the model your graphic is trying to convey.
development将分支合并到 时master，您可能进行了快进合并。
与 a git merge --no-ff（手册页）相反，“即使合并解析为快进，也会创建合并提交”。
这意味着masterHEAD 只是移动到devHEAD，引用所有dev提交。
请参阅“为什么 git 默认使用快进合并？ ”。
请按照以下步骤操作。也许你会自己找到答案。
确保您当前正在使用正确的分支
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