git-changelog 0.3.1

A tool to automate project changelog generation.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

# 1d82af9^..1d82af9 (2017-10-22)

- [Demonstrate tagging conventions for commit messages](https://github.com/aldrin/git-changelog/commit/1d82af9a1bd05c100b7b50bdcda3db39a5cddcdf)

### Features
    
- *Categorized Changes:* Lines that begin with a `- <tag>:` can
  be used to categorize changes. Everything that follows the prefix is
  tagged with the chosen category. For example, this text describes the
  tool feature that categorizes changes. Among others, `feature` is an
  out-of-the-box tag defined in the [configuration](changelog.yml). You can
  define tags that make sense for your project.

- *Scoped Changes:* For larger projects, the tool supports
  another level of organization using *scopes*. For example, projects can
  organize API changes under a `API` scope. To specify a scope, use the
  *`- <tag>(<scope>):`* prefix. When you don't specify a scope the item
  goes into the `default` scope. As with tags, you can define scopes that
  make sense for your project like `docs`, `benchmark`, etc. You can also
  ignore them entirely and just use simple category tags.

### Notes
    
- This commit message is long to demonstrate the tool features. *Real*
  commits should follow the standard
  [guidance](https://chris.beams.io/posts/git-commit/) on writing commit
  messages. The only additional (and optional) conventions this tool
  introduces are the tagging prefixes described here.

## API
    
### Breaking Changes
    
- This item is an example of a scoped *and* categorized
  change. The text here and all that follows will show up under a
  "Breaking Changes" section in the "API" scope of the project. You can
  use this to describe the change as you wish. For example, for a breaking
  change, you may want to itemize things like:
  
   - **Why** the breaking change was necessary.
   - **What** the users should do about it.
  
  You can even put code snippets like this:
  
  ```rust
  /// A single line in the change message
  #[derive(Default, Serialize)]
  pub struct Line {
      /// The scope
      pub scope: Option<String>,
      /// The category
      pub category: Option<String>,
      /// The text
      pub text: Option<String>,
  }
  ```
  
  All text that follows a tagged line is implicitly categorized under the
  currently active tags.