In Git when pushing the master branch, commits from the development branch are pushed too. Is this supposed to happen? I am using Gitflow

Question

When I started working with git I based my workflow on the Gitflow model: http://nvie.com/posts/a-successful-git-branching-model/. I thought main idea was to keep commits to appropriate branches; so that for example the main branch would only have the commits which had been merged in from the development branch ... ie the tags ... 0.1. 0.2. 1.0 in the graphic. I don't fully understand how git works or how this workflow is meant to operate but that's what I thought, especially since the graphic on that page only shows these few commits on the master branch, not all the development ones as well.

I push my repo up to Bitbucket and all went well while I was working in the development branch, however when I finished development; and and pushed up the master branch I found that the master branch in Bitbucket now contains all of the commits I made on the development branch, whereas I thought I would only contain the last commit ( the one I merged in). Can someone explain why this, and whether this is intended behaviour, and if not what I can do to get my workflow working in line with the model above. I use Smartgit.

Answer 1

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.

Answer 2

It is possible that, when merging your development branch to master, you did a fast-forward merge.
As opposed to a git merge --no-ff, which (man page) "creates a merge commit even when the merge resolves as a fast-forward".

That means master HEAD simply moved to dev HEAD, referencing all dev commits.

See "Why does git use fast-forward merging by default?".

Answer 3

Please follow these steps. May be you will find out answer on your own.

• Make sure you are currently working on correct branch

  git branch -a //Shows you all the branches 
  git checkout {branch_name} //Make sure you checkout the correct branch
  

• Make sure you have proper commits in your log

  git log --oneline -6 // Show last 6 commits on this branch
  

• If you see commits from other branch, then you might have merged that branch in your current branch or you might have made commits in this branch by mistake.