Building Enterprise JavaScript Applications
上QQ阅读APP看书,第一时间看更新

Naming sub-branches

There are multiple valid ways to name these sub-branches, but the most popular convention uses grouping tokens, with various delimiters. For example, our Facebook and Twitter login sub-branches can be grouped under the social-login grouping token, with a period (.) as a delimiter, and a sub-token such as facebook or twitter:

$ git checkout -b social-login.facebook social-login
Switched to a new branch 'social-login.facebook'
$ git branch
dev
master
  social-login
* social-login.facebook

You can use almost anything as a delimiter; the comma (,), hash (#), and greater-than sign (>) are all valid delimiters. However, there are several rules outlined under the git-check-ref-format part of the documentation that give valid reference names. For example, the following characters are unavailable: space, tilde (~), caret (^), colon (:), question mark (?), asterisk (*), and open bracket ([).

See all the rules by visiting the documentation for  git-check-ref-format at  https://git-scm.com/docs/git-check-ref-format.

Most conventions I have encountered use a forward slash (/) as the delimiter, and so we do the same here. However, this poses a problem because branches are stored as text files under .git/refs/heads. If we create a sub-branch called social-login/facebook, then it'd need to be created at .git/refs/heads/social-login/facebook, but this is impossible in our case because the social-login name is already used for the file, and thus cannot act as a directory at the same time:

$ git checkout -b social-login/facebook social-login
fatal: cannot lock ref 'refs/heads/social-login/facebook': 'refs/heads/social-login' exists; cannot create 'refs/heads/social-login/facebook'

Therefore, when we create a new feature branch, we need to provide a default sub-token, such as main. With that in mind, let's delete our current feature branches and create them again with the main sub-token:

$ git checkout dev
$ git branch -D social-login social-login.facebook
$ git checkout -b social-login/main dev
$ git branch
dev
master
* social-login/main

We are now on the social-login/main feature branch, and can start developing our social login feature.

We won't actually be writing any code; we will simply be adding text to a file to mimic new features being added. This allows us to focus on Git and not be bogged down by implementation details.

First, let's create that file and commit it to the social-login/main branch:

$ touch social-login.txt
$ git add -A && git commit -m "Add a blank social-login file"
We are using git add -A here to add all changes to the staging area.

Now, we are going to create a sub-feature branch and develop our Facebook login feature:

$ git checkout -b social-login/facebook social-login/main
$ echo "facebook" >> social-login.txt
$ git add -A && git commit -m "Implement Facebook login"

Now, do the same for the Twitter login feature, making sure to branch from the main feature branch:

$ git checkout -b social-login/twitter social-login/main
$ echo "twitter" >> social-login.txt
$ git add -A && git commit -m "Implement Twitter login"

We now have two sub-feature branches, one main feature branch, one dev branch, and our original master branch:

$ git branch
dev
master
social-login/facebook
social-login/main
* social-login/twitter
Even if you're working on your own, it's useful to create branches, because it helps you organize your code and be able to switch between working on different features very quickly.

Also note that there is no "right" way to name branches, only wrong ones. For instance, you may choose to use an additional grouping for your branches, such as feature/social-login/facebook. If you are using issue-tracking tools such as JIRA, you may also wish to add the issue ID into the branch, such as fix/HB-593/wrong-status-code. What is important is to choose a flexible scheme and be consistent with it.