Using VSCode as a Default Git Editor
Last several years I use git as my version control system (VCS) both for personal and work projects. If you are working in a team, usage of a VCS brings you a lot of benefits like change tracking, history viewing, merge issues resolving, etc. However, I have found it very handy to use even for personal projects: with git I can try different solutions simultaneously and then select the better one. Moreover, I can easily remember what I have done for a project recently. This task becomes much easier if commit messages for repository changes are written clearly and in accordance with the patterns and rules recommended by the VCS. Developers have already developed the best practices how to write commit messages. I refer the interested reader, e.g., to the article written by Chris Beams. In this article, I explain how VSCode can help writing commit messages in accordance with the rules.
Table of Contents
Introduction
For the last several years, I have used nano to write commit messages. However, it is not very convenient to do this task: you do not see what has been changed, you cannot check the amount of the characters in the current line, etc. That is why I have decided to use VSCode for writing. It should be noted that VSCode has its own “Source Control” tool that you can use to add changed files to the staging area and write a commit message. However, I prefer to use git from the command line. Moreover, in VSCode the commit message textarea does not impose the rules to get a pretty commit description.
Commit Message Rules by Chris Beams
Here is the excerpt from Chris Beams’s article on how to write pretty commit message:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
And the example:
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like 'log', 'shortlog'
and 'rebase' can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
Configuration
First, we have to set VSCode as a default editor. In order to do this, open your terminal application and run the following command:
$ git config --global core.editor "code --new-window --wait"
The --new-window option is required to open a new VSCode window to write a commit message. Of course, opening a new VSCode window brings a little delay (basically, VSCode is a web browser that executes the code developed using the Electron framework, so it is quite heavy process). However, so as I do not do a lot of commits a day the benefits of using VSCode outperforms this drawback. The --wait option is required to return the control to Bash when you close the window.
Now, you can check that VSCode is set as the default git editor and modify the rest of the settings (this command will modify the global git settings stored in the .gitconfig file):
$ git config --global -e
The minimum set of settings required to use VSCode for different git tasks is provided below:
[user]
name = Yury Zhauniarovich
email = your_email@email.com
[credential]
helper = cache --timeout=86400
[core]
editor = code --new-window --wait
[merge]
tool = vscode
[mergetool "vscode"]
cmd = code --new-window --wait $MERGED
[diff]
tool = vscode
[difftool "vscode"]
cmd = code --new-window --wait --diff $LOCAL $REMOTE
VSCode Configuration
The VSCode is great for writing commit messages for two reasons:
- The extension called “Git Commit Message Helper”, helps to write pretty commit message imposing the rules on the subject line.
- VSCode can wrap the text (using the Rewrap extension) according to the required length of the string. This is very handy because you do not need to add carriage returns manually.
In order to use this functionality, at first you need to install the extension I have mentioned. After this, make some changes in a repository, add them to the staging area and run the git commit command. The following screencast shows how these two features help me writing good commit messages:
As you can see, if you write a subject line that exceeds 50 characters the Git Commit Message Helper extension highlights the text with red color. The line length for the description of a commit should not exceed 72 characters. In order to wrap lines according to this limit, open Command Palette (Ctrl+Shift+P) and select the command “Rewrap Comment / Text at column…”, and in the opened textbox enter the required line length (72 characters). This functionality is provided by the Rewrap extension, so you need to install it before starting using this functionality.
Conclusion
With these rules and two simple features you can write better commit messages your collaborators will be thankful for.
