In Git, what is the value of including <start-point>, when creating a new branch?

Viewed 115

The documentation says that, at the simplest level, I can run either of the following 2 commands to create a new branch (deliberately ignoring the "checkout" command, for this question):

$ git  branch  <newbranchname>

--OR--

$ git  branch  <newbranchname>  <start-point-branch>

I have a gut feeling for the difference(s) but I am so new to this stuff that I am not trusting my gut.

Can you all please explain to me the advantages & disadvantages of either including or not including the "start-point-branch" at the end of that command line?

3 Answers

Without the extra argument, the newly created branch will branch out from the current HEAD. With the extra argument, it will branch out from there.

I don't think you can really discuss the advantages or disadvantages of including this argument - you should branch out from the correct commit. Once branched out, git retains no "memory" of how this branch was created. In other words, git branch new_branch some_starting_point will have the same end result as git checkout some_starting_point && git branch new_branch.

If you want to then use the branch created from current HEAD or for another commit, do not use the confusing and obsolete checkout command.

Use git switch:

git switch [<options>] (-c|-C) <new-branch> [<start-point>]

Create a new branch named <new-branch> starting at <start-point> before switching to the branch. This is a convenient shortcut for:

$ git branch <new-branch>
$ git switch <new-branch>

If you omit the start point, you remain at current HEAD, but in a new branch, and can start working right away.
But you can create (and switch to) a new branch from an existing one by adding as a starting point the branch name from which you want to work.

The <start-point> is actually a branch name, or a tree-ish:

tree-ish:

A tree object or an object that can be recursively dereferenced to a tree object.

The following are all tree-ishes:

  • a commit-ish,
  • a tree object,
  • a tag object that points to a tree object,
  • a tag object that points to a tag object that points to a tree object, etc.

Typically a human user checks out the branch that becomes the root of the new branch, and then a simple git branch new_branch is all that is needed. Not every starting point is a branch. I pass the extra argument most often when creating a branch from a tag, or a different commit than HEAD.

You can check out a tag. Git just informs you that you are in a detached state — HEAD does not point to the tip of a branch. You can certainly git branch new_branch from a detached HEAD, but this is not a natural workflow for most people. People tend to check out branches more often.

Another use case for the extra argument is one I use often when writing experimental code. I will create a branch to experiment with something. Several commits in I realize I've created complete and utter garbage. I might decide to create a new branch based on a previous commit in my experimental branch.

The last use case I can think of is an automated process or shell script. You might need to create a new branch in a script from an arbitrary commit as part of a continuous integration build.

Git needs to know the base of every new branch, and that is the purpose of the extra argument. I would say that not specifying the extra argument and assuming the new branch is created from HEAD is a convenience feature. The extra argument isn't really extra. It is required, but git intelligently assumes "the tip of the current branch" if omitted.

Related