Git: Unable to understand why branch (topic) commits/merges are happening on the master branch

Note: I am not sure whether this has been already asked, as I can't find any question fitting to my context(or I am unable to understand the existing questions' contexts')

I am loving Git these days. Especially, the topic branches. I am working on a small code sharing application. And I have got (local)branches like "master", "authentication", "bookmarks", "comments", "nose" etc...

My (intended)workflow goes something like this: Create a topic branch ==> Work on the topic branch ==> Commit the files to the branch ==> Merge the topic branch changes to the "master" branch. (And later delete the topic branch)

I tried doing the same for a couple of br开发者_运维问答anches. It worked fine. But later when I checked the git graph, even if I followed the same workflow, all the chances were happening on the "master". No tree lines diverging and converging! It shows one singe line with multiple commits from then. I am not sure why? I am of the impression, I screwed something with HEAD pointer?

To give a practical view, here is my git graph: http://github.com/none-da/zeshare/network

Here are the commands I used:

>> git branch authentication_feature
>> git checkout authentication_feature
>> # I work with all the files here in "authentication_feature" branch
>> git commit -m "Authentication_feature is up" # commiting to the branch
>> git branch # just to confirm, which branch I am working on
>> git checkout master # trying to shift to master branch
>> git merge --no-commit authentication_feature # I merge in two steps. This is step 1
>> git status;git add; git commit -m "Authentication_feature" merged to "master". # This is the step 2
>> git log --graph --pretty=oneline # confirming the graph
>> git push origin master # pushing to the remote server(github)

I bet you're looking for the --no-ff switch on git merge. By default, merge will just update the HEAD to the tip of the new branch, if there's no intervening commit.

If you want to leave the merge commit around to help with grouping your commits, pass --no-ff.

But later when I checked the git graph, even if I followed the same workflow, all the chances were happening on the "master". No tree lines diverging and converging!

Well... I do see some of your branches and merges.

You will find in this page all the possible merge scenarios
(compiled at the time - late 2007 - by now SO contributor : Jakub Narębski)

You could be in a fast-forward case, which would explain why your merges will make all your commits appear to master once they are done:

2/ Fast forward case; there are no commits A, B, C, and we start from the following situation:

   1---2---3               <-- trunk    <-- HEAD
            \
             \-a---b---c   <-- branch

2.1/ "git merge branch"

   1---2---3            /----- trunk    <-- HEAD
            \          v
             \-a---b---c   <-- branch

Fast forward results in simply moving the head of trunk.
It does not create a commit, hence:

2.2/ "git merge --no-commit branch"

Like in 2.1, because fast-forwarding does not create a commit.

So if you did not commit on master since you branched out, and then do a merge on master, all you do is resetting master HEAD...

Another cause for branches to not be displayed is the "to-do list effect" described on the presentation page of the GitHub Network Graph visualizer (which is the "git graph" you are referring to here)

But you are seeing each commit only once. Let that sink in for a second.
I find that many coders are so used to a centralized SCM that they miss the fact that our Graph Visualizer is actually showing and connecting disparate repositories.

If I draw the graph with myself as root, then the graph shows a sort of to-do list of code that I haven’t pulled into my repo yet.
When I want to catch up on what the community has been doing in their forks of my repo, I can hit up the graph and see immediately what others have been up to.
If I were to pull in Bertg’s changes, the next time I see the graph, Bertg will no longer be shown at all because he will no longer have any commits that I do not.
Keep thinking to-do list and you’ll understand the graph.

So if that is true for merges from other repos branches (i.e. you do not see those branches anymore once they are merged), that may be true for merges from your own repo branches: once merged, you do not see them anymore in your graph.

But I do, since:

• I am not the owner of the project.
• I may want to pull in my repo changes from any of your branches.

Are you using something like

git show-branch

to show you the branches and check-ins, once you merged your branches to master you can't see anymore revisions - not sure why.

I can't find any explanation about the behavior but there does not seem to be any problem with git repository since git log shows all commits for each branch.

So I guess it's just the way the tool displays branch graph.

I am brand new to git and github myself (and the link is still down), but after looking at your steps, could it be because you didn't push the actual branch to github? This seems to be working for me so far (I inserted the push command):

...
>> git commit -m "Authentication_feature is up" # commiting to the branch
>> git branch # just to confirm, which branch I am working on
>> git push origin authentication_feature # push the branch to github
>> git checkout master # trying to shift to master branch
...

You did not say what commands you actually used, but my guess is that you created your branch with git branch but did not check it out to move to the branch. You can do this in one step as follows:

git checkout master -b topic22

This makes it less likely you will inadvertently commit to master.

Now that you've added the sequence of commands you did, I see you did checkout the branch.

The command sequence looks fine. I think the reason it looks like there was no branch is because there was no intervening commit on the master branch. After the merge, it looks like a sequential development flow. This is well discussed in one of the other answers so no need to elaborate here.

As an alternative to using git merge --no-ff:

If you want to commit the effect of the topic branch development to the main branch, but not all of the individual commits, then you can use git merge --squash. When you do this the commit is not marked as a merge and does not have a second parent of the topic branch. The list of individual commits is included in the commit comment for the squashed merge, as they would be listed by git log.

We have been using this in a project that is linked to SVN (by git svn), so that our main branch has a linear history. That way, we don't have to flatten the git commit graph before running git svn dcommit.