In plain language (hopefully with a simple example), what do the ahead/behind metrics on a Github repo's branch mean?
And what are the implications for that branch and the attention it's receiving? Is being "behind" a bad sign for a branch?
Ahead is the number of commits on this branch that do not exist on the base branch. Behind is the number of commits on the base branch that do not exist on this branch.
Ahead and behind are almost like a kind of "age" metric. The ahead number tells you roughly how much impact the branch will have on the base branch should it be merged. The behind number tells you how much work has happened on the base branch since this branch was started.
I find the behind number really useful for judging whether a branch is likely to merge cleanly. When a lot of work has happened on the base branch, it's more likely that the two branches have modified the same line(s). When behind is large, it's a sign that you should probably merge the base branch into this branch to sync up. Once you merge the base branch into this branch, behind will be 0.
If you're more of a visual type, take a look here:
◈ - ◈ - A - ◈ - B
\
◈ - C
A is 2 commits behind and 0 commits ahead of B
B is 0 commits behind and 2 commits ahead of A
C is 1 commit behind and 2 commits ahead of A
C is 3 commits behind and 2 commits ahead of B
So "behind" means the other branch has commits this one doesn't, and "ahead" means this branch has commits the other does not.
The metrics like those you can see for this project describe, compare to a branch from the repo (like master):
the number of new commits that the GitHub repo has done compared to another branch of another repo: those are the behind commits: the other repo is behind compared to the current repo (see those commits).
the number of new commits another branch of another repo has done compared to the current repo: those are the ahead commits: the other repo is ahead compared to the current repo (see those commits).
The technical detail is illustrated by the script "determining which repos are ahead/behind origin":
It is about checking:
what commits are reachable from another branch, but not from the local branch: ahead
git rev-list "$localref..$anotherref"
what commits are reachable from the local branch, but not from the other branch: behind
git rev-list "$anotherref..$localref"
On thing to note is that github's "behind" also counts merge commits. You can check the "behind" stuff with: git log mybranch1 ^mybranch2 and it should show you the same number of commits. If you have merge commits you can exclude them with --no-merges in the last command.
Related
I am analyzing commits from project apache/mina-sshd but I am running to a problem:
All commits in the branch 0.9.x from project mina-sshd (except for the first 3 commits) belongs to branch master but still be shown in branch 0.9.x. Can anyone explain this for me, please? I am thinking it might be because those commits are merged, maybe?
Is there anyway to check what branch a commit belongs to by Python?
Your branch 0.9.x is derived from master. So at the point the branch gets created, it contains all the commits that the other branch has at that point. If you add additional commits to the master after the branch is created, they will not appear anymore unless you merge them.
Using the basic git commands, when I am in my master branch, via TerminalBash, I create a new branch (git checkout -b twomics) and then stage and commit and push, but I do not see the branching in SourceTree. Why is that?
I have attached an image. It does not make a difference whether I choose the All Branches or Current Branch tab...
I have had other issues with this (e.g. this post) so I am wondering if it is just me or am I missing something?
A Git branch is a pointer to a commit. Both branches (master and twomics) are clearly visible in the screenshot you posted.
Because twomics started from master and master didn't change its position since you have created twomics (more exactly, there is no new commit added on master), a Git graphic client does not have any reason to show divergent branches (as in "tree branches") on the graph.
Your branches did not diverge. All project history included in the master branch is also included in the twomics change. master is an ancestor of twomics.
The twomics branch is two commits ahead of master. Merging twomics into master can be done using "fast-forward" because the two branches did not diverge.
A "fast-forward" merge means the target branch (master here) is pushed forward until it reaches the source branch (twomics). This type of merge is possible only when the target branch is an ancestor of the source branch (and it is the default type of merge when it is possible).
I had master branch which had all my code commits.Few days back I've cut a new branch from master called dev.I made some commits in both the branches..Now I want to get all commits in master branch after dev is cut from it..
Is there any command for this .Can someone help me quickly
Thanks!
By "get all commits" do you want to simply view the commits, or incorporate them into your dev branch?
If you want to add them into your branch, you'll probably want to git pull or git fetch depending on your endgame. This thread covers the difference pretty well: What is the difference between 'git pull' and 'git fetch'?
It's surprisingly simple:
git log dev..master
Just to elaborate and put an end to the confusion having resulted in 16 comments:
There is a huge difference between using two dots .. or three dots ... between the branch ids:
With two .. you get all new commits only on master since they have diverged.
With three ... you get all commits on both dev and master since they have diverged.
I was working locally on master branch. (by mistake) but it's ok with me this time as I control my code.
I took the following steps:
Egit->commit and push (to master)
Egit -> pull (to get other developers changes)
I got a message that there is a conflict with one file and I merged it.
Now I see: [My Product | Merged Master (up arrow)2 (down arrow)1]
I see in the symbols next to the files that the other developers created - black sign as if there are uncommitted.
A. What does the 2 up arrow and 1 down arrow mean?
B. Why do I see uncommitted changes? they are not mine
C. How can I work out on master after my merge?
D. I looked in bitbucket and didn't see that my changes were committed to the remote branch. What is wrong?
I know that I am supposed to work on branches - but for now - how do I fix the situation?
A. Two arrows up means you have two commits in your local branch that aren't in the remove branch. The one arrow down means there is one commit in the remote branch that you don't have locally. The solution is to do a git pull followed by a git push
B. Uncommitted changes are probably from your conflict. After a conflict, you have to resolve the conflict, add it to index and then commit that change. This is known as a merge commit. My guess is you have not done this.
C. Work out on master? You mean you want to work directly on top of master? After you resolve your conflict, you should be all set to do that. Branching is better though. To create your own branch just do git checkout -b my_featue_branch
I've done a few pull requests on GH already, but I committed to the master branch. Now I read on various places that it's a good idea to create a branch.
Are there any guidelines for branch naming? I usually work with Mercurial and give my branches the same name as their relevant bug ticket ID, but that doesn't work for this.
I've looked at a few repositories: some commit to master, some commit to fix-somebug, some commit to patch-1. I understand that this doesn't create conflicts, because pull requests are merged to master (or a different, long living branch) and the branch is then deleted, is that correct?
The idea behind a branch for a pull request is to allow for said branch to be automatically deleted once the pull request is accepted.
And since April 2013, that branch will be deleted for you:
You are then suppose to update/rebase your master from the master of the upstream repo in order to get what you developed in isolation a branch from the official repo that you have forked (since that repo has accepted your pull request)
The name of the branch should represent the development effort you are engaged in.
It is always a good practise to make commit on the git branches rather than master. You can use any name for your git branch(it doesn't allow spaces in branch names, also some special characters).