How can I tell what GIT branches are not fully merged?

Question

So I'm interested in opinions about my current GIT workflow (which I'm new to), and how to determine which of my changes have not yet been merged/pushed to the appropriate repositories. So first off, my current system looks like this:

      remote.master
            |
            |
            V
      local.master
   |       |       |
   V       V       V
 branch  branch   branch

For a new task, I would pull from remote.master to local.master, create a new branch and check it out. I would do various commits while working on the task, maybe switching to other tasks, and then when ready, would pull from remote.master to local.master, merge my branch to local.master, and finally push to remote.master.

So 2 questions: for a small team, is this overkill? Does it make more sense to omit the local branches? If so, some advice suggests there will be either problems with 'fast forwarding' (which I understand makes changes indistinguishable in remote.master) or a plethora of commit that have potentially unexpected timestamps and are difficult to parse through.

2nd, assuming the above workflow: I sometimes switch between tasks frequently. I want a screen that shows me:

'branch 01' -> partially merged to local.master 
'branch 04' -> notmerged to local.master 
'local.master' -> partially merged to remote.master

It can happen that I forget if various features have been merged, and to where. I definitely don't want to go branch-by-branch and attempt to divine this info through 'git diff' or other commands. I currently use Tortoise GIT on Windows, but am open to other graphical alternatives. I do use the shell at times, but prefer a UI. Is there a way to get this info?

Nobe

I would not omit the local branches; by default, git branch shows only the local ones. But I think you're thinking that branches are more than they actually are: they are really just "sticky notes" of a sort, pasted onto particular commits. When you commit something to a branch, this adds a new commit and moves the sticky note forward. The actual branches are always determined dynamically from the commit graph. It's left up to the user to keep branch label names sensible. – Antipodal

Answer 1

Whatever you want to do in your local environment is not overkill. If you want to have 100 local branches, that's totally up to you, and if that turns out to be overkill (probably), then you can scale back appropriately.

The "problems with fast-forwarding" are a matter of taste. The default behavior of Git is to fast-forward instead of merge if the two branches have not diverged. Like the author, I also don't like this, but I would not call it a "problem". As a workaround, I perform merges like this:

# merge branch without fast forward and commit
git merge --no-ff --no-commit branchname

# code review
git diff

# commit the merge
git commit -m 'merged: branchname'

I use the alias rev = merge --no-ff --no-commit to simplify the merge step to git rev branchname (named "rev" as in "review", as in "code review").

To view a log of only the merge commits, use another alias: revlog = log --first-parent

Since I use a separate branch for every feature, this way I can see the large steps in the evolution of project, like a change log.

For your 2nd question, I think you're looking for these commands:

# view the branches that have been merged already
git branch --merged

# view the branches that have NOT been merged yet
git branch --no-merged

I don't know Tortoise, but gitk is pretty nice, if I remember correctly it's included with Git Bash.

Artemus