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.
Related
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'm new to Github and I have a branch that I want to merge with the master. I couldn't merge it via git command line, its very complicated.
I tried to merge it on Github site following below documentation:
Merging a pull request on GitHub
But I got the following message:
There isn’t anything to compare!
Here's the project:
https://github.com/SumayahAlharbi/erecords
What does 4 commits behind master mean?
Update
Please check below pictures:
I thought I did the merging successfully but nothing changes!
What does 4 commits behind master mean?
It means that the master branch has 4 commits which are not present in your branch currently. You need to rebase your branch and then create a New Pull
Request which will be needed to be reviewed and finally approved so
that your branch can be merged with the master.
There isn’t anything to compare!
Check the difference between the master and your branch. Click the Compare icon in Git hub or run this
command from your local branch in Git Bash : git diff --name-only master_branch.
I just checked your repo. The changes of ExportFeature branch are already merged into the master branch, and then the merge is reverted. That's why now if you raise a pull request to merge ExportFeature into master, you would get There isn’t anything to compare!.
See the latest commits on ExportFeature which are already present in the master branch.
The reason you are seeing 4 commits behind master on ExportFeature branch is since the master branch has 4 more commits than the ExportFeature branch. If you see the total commits on ExportFeature branch, it's 7, whereas the total number of commits on the master branch is 11. If you need to do any more changes on the ExportFeature branch, you would need to get the latest changes from the master branch by running the command git pull origin master when your current branch is ExportFeature on your local git terminal.
In my git repository I have three branches: master: default, dev: compare, and temp.
When I create a Pull Request from temp branch it defaults to dev as the target.
It is in contradiction with what Microsoft documentation says:
Change the default branch used to merge code into when your team
creates new pull requests. This is useful when you want to use a
branch other than master for the main line of development in your
repo.
Am I missing something?
For default branch, it helps you to treat the branch as default when cloning the git repo locally or creating a PR.
Such as if you treat master branch as default branch (by default), when you cloned the git repo locally, the local branch is master. And when you creating a PR, it will automatically treat master branch as the target branch.
For compare branch, it helps you to decide how many commits on the other branches are behind or ahead by comparing commits on other branches with the compare branch.
Such as for above example, develop branch is compare branch, and master branch and nn1 branch are compare with develop branch.
For comparing master branch with develop branch, there has 0 commits behind and 0 commit ahead (master branch same as develop branch). For comparing nn1 branch with develop branch, there are 3 commits behind and 48 commits ahead.
I did some quick tests in my VSTS tenant. It looks like the default branch of a new pull request is always the Compare branch, rather than the Default branch. So if you set your master branch as Compare branch, it should become to the default for new pull requests.
Not sure if it is bug of VSTS, or if they change the behavior of pull request without updating the doc.
Update:
I did some further research. It turned out that this change was introduced in a Oct 2016 feature roll out:
You can now set your compare branch to something other than the
default branch. This setting will be remembered on a per-user basis.
Pull requests and new branches created from the Branches page will be
based off the branch you set as the compare branch.
So the doc needs to be updated.
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).
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.