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).
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.
The normal GitHub flow to contribute to a repo is to create a fork of the upstream, clone a local copy where you make changes, then push back up to your fork and then create a PR to have your changes merged into upstream.
But if upstream changes after that, how do you update your fork without creating a merge commit (and also without using the git CLI)?
I already know how to do this in a way that will create a merge commit or which depend on the git command line interface. This question is specifically about using the GitHub.com website or GitHub Desktop application only (no CLI).
Since this is a very common workflow it seems like there should be some simple way to do it using the GitHub GUI.
To reiterate: any answers that use the CLI or create a merge commit (e.g. this way) will not be answering this question since I'm explicitly looking for a non-CLI solution.
without a merge commit or using CLI?
Not directly with GitHub web UI alone, since it would involve rebasing your PR branch on top of upstream/master
So in short: no.
But in less short... maybe, if you really want to try it.
Rebasing through GitHub web UI is actually possible, since Sept. 2016, ...
if you are the maintainer of the original repo, wanting to integrate a PR branch
if none of the replayed commit introduces a conflict
(This differs from GitHub Desktop, which, since June 5th 2019 does support rebasing. But that is a frontend to Git CLI, like other tools provide. For example GitKraken and interactive rebase)
So a convoluted workaround would be:
to fetch, then push upstream/master to the master branch of your own fork (a CLI operation, but more on that below)
change the base branch of your current PR to master (so a PR within the same repository: your own fork), provided you haven't pushed to master.
Meaning: master in your fork represents the updated upstream/master, with upstream being the original repository that you have forked.
Since you are the owner of that repository (your fork), GitHub can then show you if you can rebase said branch to the base branch of the PR (master), but only if there is no conflict.
finally, change the base branch again, to <originalRepo>/master (which is the intended target of your PR)
The very first step is typically done through command line, but... there might be a trick to do it (update upstream master in your fork) through web UI: see "Quick Tip: Sync a Fork with the Original via GitHub’s Web UI" by Bruno Skvorc
In short, it involves:
creating a new branch from your current master (which would be at upstream/master at the time you forked the original repository)
Making a PR with that new branch and <originalRepo/master>
doing a base switch before creating the PR
That is the step which artificially forces upstream/master to be refreshed
You can the create and merge it with the “Merge Pull Request” button (and “Confirm Merge” afterwards): the merge will be trivial: no merge commit.
The end result is: your own master branch (in your fork) updated with upstream/master (the master branch of the original repository)!
You can then resume the steps I describe above, and change the base of your current PR to your own (now refreshed) master branch, and see if you can rebase it!
This is feasible with GitHub Desktop since version 1.0.7 considering the following:
If the current branch does not have any commits ahead upstream (the original repo of the fork), the new commits can be pulled without creating a new merge commit
In GitHub Desktop:
Clone your repository from File > Clone Repository
Fetch origin, which will automatically fetch the upstream as well
Go to Branches by clicking on where it says Current Branch
Click on Choose a branch to merge into <branch> at the bottom
Search for upstream/<branch>, then click Merge upstream/<branch> into <branch>
Push to origin, et voilà!
Otherwise, ff the current branch has commits ahead of the fork, then of course one has to create a merge commit or rebase and force push. For rebasing which might be more preferable, do the following:
In GItHub Desktop, go to Branch from menu, then Rebase Current Branch
Search for upstream/<branch>, then click Start Rebase
Solve any conflicts that have occurred from the rebase
Force push to origin. You will get a warning for this for obvious reasons.
For avoiding force-pushing to your work when your current branch is both ahead and behind its upstream counterpart, either create a new merge commit or:
Make a new branch based with all your changes
If needed, reset the original branch to its original state (before it diverged from the original repo)
Perform the steps from the first scenario and merge your changes into your branch.
And yes, it seems that pulling via the GitHub website from the original repo without creating a pull request and merge commit is not possible at this moment.
Demo GIF for first scenario: https://imgur.com/a/8wci2yf
Some GitHub issues related to this:
Add an upstream to forked repositories
multi-remote support in Desktop
Update
Note: Non-CLI based approach that might help:
Is there a way to make GitHub Desktop rebase a branch against master?
The only key here is doing a rebase, so the above answer should help.
CLI way (which is easier and using git, so it should be more comprehensive by default)
There are some practices that you should use to avoid this.
Don't work on the master branch in your fork.
$ git clone <your fork>
$ git checkout -b feature_branch
You can work in your feature_branch and then raise a Pull Request.
Once your changes are merged in the upstream master, you can pull from upstream to your origin. Since the master on upstream will have your commits sitting neatly on top of it, there won't be a merge commit.
$ git checkout master
$ git pull upstream master
$ git push origin master
In the case, where the maintainer has diverged from the master that you have in your fork, that is, it's not linear any more, you need to pull a fresh copy of it. That should not be a problem as your changes are already in the upstream.
If the master in upstream has moved ahead while you were working on your PR, then you can rebase on you feature_branch.
$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master
Please refer to this document for detailed reference: Fork and pull request workflow
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 have a forked a repo on GitHub. I have a master on this fork so that I can branch features separately and do pull requests to the upstream/master per feature. The only time my master changes is when the origin changes, meaning I don't merge my features into my master. I have updated my master from the origin and I now need to merge those changes into one of my feature branches.
The problem I am encountering is that I seem to have about 40 Unstaged files in my master branch. There appears to be 2 to 3 of each file marked: ~Automatic Revision, ~HEAD, or ~HEAD_0.
I am not terribly familiar with Git, though the basic concepts seem to be straight forward. I think most of my issues are me not understanding how sourcetree works.
First, Why would there be Unstaged/Uncommitted changes immediately after checking out my master?
Second, How can I be sure I am merging a complete copy of my master to my feature branch so that I am not unnecessarily altering files that are not part of my feature changes while issuing my pull request from my feature branch back to the upstream/master?
Resolved by deleting and re-cloning master branch.
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.