If you are using this form of the
branch command (with start point), it does not matter where your
What you are doing:
git checkout dev git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
First, you set your
HEADto the branch
Second, you start a new branch on commit
07aeec98. There is no bb.txt at this commit (according to your github repo).
If you want to start a new branch at the location you have just checked out, you can either run branch with no start point:
git branch test
or as other have answered, branch and checkout there in one operation:
git checkout -b test
I think that you might be confused by that fact that
07aeec98 is part of the branch
dev. It is true that this commit is an ancestor of
dev, its changes are needed to reach the latest commit in
dev. However, they are other commits that are needed to reach the latest
dev, and these are not necessarily in the history of
8480e8ae (where you added bb.txt) is for example not in the history of
07aeec98. If you branch from
07aeec98, you won't get the changes introduced by
In other words: if you merge branch A and branch B into branch C, then create a new branch on a commit of A, you won't get the changes introduced in B.
Same here, you had two parallel branches master and dev, which you merged in dev. Branching out from a commit of master (older than the merge) won't provide you with the changes of dev.
If you want to permanently integrate new changes from master into your feature branches, you should merge
master into them and go on. This will create merge commits in your feature branches, though.
If you have not published your feature branches, you can also rebase them on the updated master:
git rebase master featureA. Be prepared to solve possible conflicts.
If you want a workflow where you can work on feature branches free of merge commits and still integrate with newer changes in master, I recommend the following:
- base every new feature branch on a commit of master
- create a
devbranch on a commit of master
- when you need to see how your feature branch integrates with new changes in master, merge both master and the feature branch into
Do not commit into
dev directly, use it only for merging other branches.
For example, if you are working on feature A and B:
a---b---c---d---e---f---g -master \ \ \ \-x -featureB \ \-j---k -featureA
Merge branches into a
dev branch to check if they work well with the new master:
a---b---c---d---e---f---g -master \ \ \ \ \ \--x'---k' -dev \ \ / / \ \-x---------- / -featureB \ / \-j---k--------------- -featureA
You can continue working on your feature branches, and keep merging in new changes from both master and feature branches into
a---b---c---d---e---f---g---h---i----- -master \ \ \ \ \ \ \--x'---k'---i'---l' -dev \ \ / / / \ \-x---------- / / -featureB \ / / \-j---k-----------------l------ -featureA
When it is time to integrate the new features, merge the feature branches (not
dev!) into master.