7

We are using GitHub to store our code repositories, and we would like all developers to ensure that branches are up to date with master before doing local developer testing, and merging.

There are two ways of updating a branch with the commits of master:

  1. Merge master into my branch feature_branch, and push feature_branch
  2. Rebase my branch feature_branch onto master, and force push feature_branch.

Given that the team in question is currently using 1. (merge workflow), how can I see:

  1. The number of commits that are in the remote master branch, but not in the remote feature_branch.
  2. A true value if the number in 1 is >0, otherwise false.

It would be most preferable to have something that integrates with GitHub do this, but I'd like to know how to do this from the command line as well.

I know that I can do a git diff master..feature_branch, but that actually gives me all the changes (and is for the local branches). I just want to know the number of commits ahead and behind, in the same manner than it is shown between local master and remote master

Steve
  • 2,764
  • 4
  • 27
  • 32
  • "force push" is asking for trouble down the road. – Thorbjørn Ravn Andersen Jul 22 '16 at 13:45
  • yes, it can be, but there are pros and cons, one pro being a cleaner history, but this question is not intended to discuss rebase vs merge workflow. Force pushing a feature branch that one guy is working on is not really a problem in my eyes. – Steve Jul 22 '16 at 13:46

2 Answers2

8

Jeff Puckett II's answer is fine, and you should follow his link to this other answer as well. But what you want is in fact built directly in to Git:

git rev-list --count master..feature

and:

git rev-list --count feature..master

which you might want to combine into very short alias or script:

echo feature is $(git rev-list --count master..feature) commits ahead of master
echo and $(git rev-list --count feature..master) commits behind master

This is, in fact, just what git status and git branch -vv do, although they check for zero-commits-ahead-or-behind first too.

Here's a short (very short, for me :-) ) explanation.

Git's log and rev-list are almost the same command

Both git log and git rev-list look at a whole range of commits. The most important difference is that git log shows you the log messages (and optionally, patches), while git rev-list shows you just the raw commit hashes, by default.

You can, however, get git rev-list to give you a count of how many commits it would have listed, instead of their raw hash IDs. And, as you will see in pretty diagrams on that other answer, the stop..start two-dot syntax (except in git diff which is very special1) tells Git "give me all the commits you can find starting from start, excluding all the commits you can find starting from stop".

If you find all the commits that are on feature, then take away all the commits that are on both branches, you're left with only the commits that are only on feature. Then you have git rev-list count them. These are the commits you're "ahead", so that's how far ahead you are.

(Having git log log them, each on one line, then getting wc to count the lines, also works, of course.)

Reversing the two names, with feature..master, has Git find commits that are on master, then take away commits on both branches. These are the ones you're "behind".

The output of git rev-list is rarely useful for humans, and is mainly intended to be used in scripts. In fact, that's just what I suggested above: a two line script (or even just one line, but that did not fit very well on my screen here).

Here's a question for thought: how do we know to use the names master and feature? How could we instruct Git to know this? But let's leave that for later.

1The issue here is that git diff desperately wants to work with at most two commits. The range notations with two and three dots, master..feature or master...feature, usually produce a long list of commits. Git's diff can't handle these anyway. It could just refuse to take these notations—which would have been quite reasonable, really—but instead, the Git authors decided they'd re-use the notations to mean something related.

This means that whatever you've learned about using master..feature with git diff, you must forget it all whenever dealing with other Git commands. Sic transit gloria Git.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • There is a small typo here `echo and $(git rev-list --count master..feature) commits behind master` – Steve Jul 25 '16 at 17:58
2

Instead of diff

git diff master..feature

use log

git log master..feature

See this answer for a great explanation.

So if you just want the count, then use --oneline and pipe it to word count line.

git log --oneline master..feature | wc -l
Community
  • 1
  • 1
Jeff Puckett
  • 37,464
  • 17
  • 118
  • 167