feat: verify minimum required git version is installed

README.md

@@ -68,9 +68,9 @@ Here is an example of the release type that will be done based on a commit messa
 
 ### Triggering a release
 
-When pushing new commits to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are relevant codebase changes since the last release.
+For each new commits added to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
 
-By default a release will be done for each push to the release branch that contains relevant code changes. If you need more control over the timing of releases you have a couple of options:
+If you need more control over the timing of releases you have a couple of options:
 - Publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)). This way you can keep control over what your users end up using by default, and you can decide when to make an automatically released version available to the stable channel, and promote it.
 - Develop on a `dev` branch and merge it to the release branch (i.e. `master`) once you are ready to publish. **semantic-release** will run only on pushes to the release branch.
 
@@ -83,11 +83,11 @@ After running the tests the command `semantic-release` will execute the followin
 | Verify Conditions | Verify all the conditions to proceed with the release with the [verify conditions plugins](docs/usage/plugins.md#verifyconditions-plugin).                            |
 | Get last release  | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging).                                       |
 | Analyze commits   | Determine the type of release with the [analyze commits plugin](docs/usage/plugins.md#analyzecommits-plugin) based on the commits added since the last release.       |
-| Verify release    | Verify the release conformity with the [verify release plugins](docs/usage/plugins.md#verifyrelease-plugin).                                                           |
+| Verify release    | Verify the release conformity with the [verify release plugins](docs/usage/plugins.md#verifyrelease-plugin).                                                          |
 | Generate notes    | Generate release notes with the [generate notes plugin](docs/usage/plugins.md#generatenotes-plugin) for the commits added since the last release.                     |
 | Create Git tag    | Create a Git tag corresponding to the new release version                                                                                                             |
-| Prepare           | Prepare the release with the [prepare plugins](docs/usage/plugins.md#prepare-plugin).                                                                                  |
-| Publish           | Publish the release with the [publish plugins](docs/usage/plugins.md#publish-plugin).                                                                                  |
+| Prepare           | Prepare the release with the [prepare plugins](docs/usage/plugins.md#prepare-plugin).                                                                                 |
+| Publish           | Publish the release with the [publish plugins](docs/usage/plugins.md#publish-plugin).                                                                                 |
 | Notify            | Notify of new releases or errors with the [success](docs/usage/plugins.md#success-plugin) and [fail](docs/usage/plugins.md#fail-plugin) plugins.                      |
 
 ## Documentation

bin/semantic-release.js

@@ -3,11 +3,15 @@
 // Bad news: We have to write plain ES5 in this file
 // Good news: It's the only file of the entire project
 
-/* eslint-disable no-var */
+/* eslint-disable no-var, promise/prefer-await-to-then, prefer-destructuring */
 
 var semver = require('semver');
+var execa = require('execa');
+var findVersions = require('find-versions');
 var pkg = require('../package.json');
 
+var MIN_GIT_VERSION = '2.0.0';
+
 if (!semver.satisfies(process.version, pkg.engines.node)) {
   console.error(
     `[semantic-release]: node version ${pkg.engines.node} is required. Found ${process.version}.
@@ -17,6 +21,21 @@ See https://github.com/semantic-release/semantic-release/blob/caribou/docs/suppo
   process.exit(1);
 }
 
+execa
+  .stdout('git', ['--version'])
+  .then(stdout => {
+    var gitVersion = findVersions(stdout)[0];
+    if (semver.lt(gitVersion, MIN_GIT_VERSION)) {
+      console.error(`[semantic-release]: Git version ${MIN_GIT_VERSION} is required. Found ${gitVersion}.`);
+      process.exit(1);
+    }
+  })
+  .catch(err => {
+    console.error(`[semantic-release]: Git version ${MIN_GIT_VERSION} is required. No git binary found.`);
+    console.error(err);
+    process.exit(1);
+  });
+
 // Node 8+ from this point on
 require('../cli')().catch(() => {
   process.exitCode = 1;

docs/support/FAQ.md

@@ -164,6 +164,21 @@ You can trigger a release by pushing to your Git repository. You deliberately ca
 
 Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
 
+## How can I change the type of commits that trigger a release?
+
+By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
+
+| Commit                      | Release type               |
+|-----------------------------|----------------------------|
+| Commit with breaking change | ~~Major~~ Breaking release |
+| Commit with type `feat`     | ~~Minor~~ Feature release  |
+| Commit with type `fix`      | Patch release              |
+| Commit with type `perf`     | Patch release              |
+
+See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
+
+This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
+
 ## Is it *really* a good idea to release on every push?
 
 It is indeed a great idea because it *forces* you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
@@ -174,6 +189,8 @@ From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow
 
 If you need more control over the timing of releases, see [Triggering a release](../../README.md#triggering-a-release) for different options.
 
+**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
+
 ## Can I set the initial release version of my package to `0.0.1`?
 
 This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.
@@ -194,7 +211,7 @@ In addition the [verify conditions step](../../README.md#release-steps) verifies
 
 See [Node version requirement](../support/node-version.md#node-version-requirement) for more details and solutions.
 
-# What is npx?
+## What is npx?
 
 [`npx`](https://www.npmjs.com/package/npx) – short for "npm exec" – is a CLI to find and execute npm binaries within the local `node_modules` folder or in the $PATH. If a binary can't be located npx will download the required package and execute it from its cache location.
 The tool is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.2, or can be installed via `npm install -g npx`.

lib/git.js

@@ -69,7 +69,7 @@ async function gitHead() {
  */
 async function repoUrl() {
   try {
-    return await execa.stdout('git', ['remote', 'get-url', 'origin']);
+    return await execa.stdout('git', ['config', '--get', 'remote.origin.url']);
   } catch (err) {
     debug(err);
   }

package.json

@@ -30,14 +30,15 @@
     "debug": "^3.1.0",
     "env-ci": "^2.0.0",
     "execa": "^0.10.0",
+    "find-versions": "^2.0.0",
     "get-stream": "^3.0.0",
     "git-log-parser": "^1.2.0",
     "git-url-parse": "^9.0.0",
     "hook-std": "^0.4.0",
     "hosted-git-info": "^2.6.0",
     "lodash": "^4.17.4",
-    "marked": "^0.3.9",
-    "marked-terminal": "^2.0.0",
+    "marked": "^0.4.0",
+    "marked-terminal": "^3.0.0",
     "p-locate": "^2.0.0",
     "p-reduce": "^1.0.0",
     "read-pkg-up": "^3.0.0",