web-dev-qa-db-ja.com

gitを使用して変更ログを管理する良い方法は？

私はしばらくGitを使用していますが、最近リリースをタグ付けするために使用し始め、変更をより簡単に追跡し、各クライアントが実行しているバージョンを確認できるようにしました（残念ながら、現在のコードでは各クライアントがPHPサイトの独自のコピーを持っていること、私はこれを変更していますが、時間がかかります）。

いずれにせよ、私たちはある程度の勢いをつけ始めています。前回のリリース以降に何が変わったのかを人々に示すことができれば本当に良いと思いました。問題は、変更ログを管理する方法がよくわからないため、変更ログを保持していないことです。この特定の時間については、ログを実行して手動で作成できますが、それはすぐに疲れるでしょう。

「git changelog」と「git manage changelog」をググググしてみましたが、コード変更のワークフローと、それがchangelogとどのように一致するかについて本当に話をするものは見つかりませんでした。私たちは現在 Rein Henrichsの開発ワークフロー をフォローしており、それに沿ったものが欲しいです。

私が見逃している標準的なアプローチはありますか、それとも誰もが自分のことをするエリアですか？

コメント/回答ありがとうございました！

gitgithubchangelog
195
Topher Fangio

これは約3〜4年前ですが、将来の検索者のために、次のように豪華なログを生成できるようになりました。

git log --oneline --decorate

または、さらにきれいにしたい場合（ターミナルの色付き）：

git log --oneline --decorate --color

その出力をChangeLogにパイピングすることは、すべてのプロジェクトで現在使用しているもので、単純に驚くべきことです。

159
user1241335

いくつかの種類のgit logを使用してあなたを助けることができます：

git log --pretty=%s                 # only print the subject

ブランチに適切な名前を付けて、マスターへのマージが「Merged branch feature-foobar」のように表示される場合、マージしたすべての小さなコミットではなく、そのメッセージのみを表示することで短縮できます。特徴：

git log --pretty=%s --first-parent  # only follow first parent of merges

独自のスクリプトを使用してこれを補強することができます。これにより、「マージされたブランチ」ビットの削除、フォーマットの正規化などが可能になります。もちろん、いつかは自分で作成する必要があります。

次に、バージョンごとに1回、変更ログの新しいセクションを作成できます。

git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y

バージョンリリースコミットでそれをコミットします。

問題が、それらのコミットサブジェクトが変更ログに入れたいものとは異なる場合、ほとんど2つのオプションがあります：すべてを手動でやり続ける（そして、キャッチを再生するのではなく、もっと定期的に追いかけるリリース時にアップ）、またはコミットメッセージスタイルを修正します。サブジェクトがあなたのためにそれをしないなら、1つのオプションはあなたのコミットメッセージの本文に「change：added feature foobar」のような行を置くことです。そうすれば後でgit log --pretty=%B | grep ^change:のようなことをすることができますメッセージの非常に重要な部分のみを取得します。

そのgitがどれだけあなたがchangelogを作成するのに本当に役立つのか、私には完全にはわかりません。多分私はあなたが「管理」によって意味するものを誤って解釈したのでしょうか？

56
Cascabel

免責事項：私は gitchangelog の著者です。

TL; DR：gitchangelog自身のchangelog または生成された ascii output 以前。

Git履歴から変更ログを生成する場合は、おそらく以下を考慮する必要があります。

  • 出力フォーマット。 （純粋なカスタムASCII、Debian変更ログタイプ、Markdow、ReST ...）
  • somecommit filtering（おそらく、変更ログに表示されるタイプミスや表面的な変更をすべて表示したくないでしょう）
  • いくつかは、変更ログに含まれる前にテキストラングリングをコミットします。 （最初の文字を大文字または最後のドットにすることでメッセージの正規化を保証しますが、要約の特別なマークアップを削除することもできます）
  • あなたのgit history compatible？マージ、タグ付けは、ほとんどのツールで常にそれほど簡単にサポートされているわけではありません。履歴の管理方法によって異なります。

オプションで、いくつかの分類（新しいもの、変更、バグ修正）が必要な場合があります...

これらすべてを念頭に置いて、 gitchangelog を作成して使用します。 gitコミットメッセージ規約を活用して、以前の目標をすべて達成することを意図しています。

Nice changelogを作成するには、コミットメッセージの規則が必須です（gitchangelogを使用する場合と使用しない場合）。

メッセージ規約をコミットする

以下は、コミットメッセージの追加について考えるのに役立つと思われるものへの提案です。

コミットを大まかなセクションに大まかに分けたい場合があります。

  • 意図により（例：新規、修正、変更...）
  • オブジェクトごと（例：ドキュメント、パッケージ、コード...）
  • 対象者（例：開発者、テスター、ユーザー...）

さらに、いくつかのコミットにタグを付けることもできます。

  • 変更ログに出力されるべきではない「マイナー」コミットとして（化粧品の変更、コメントの小さな誤植など）
  • 重要な機能変更が実際にない場合は、「リファクタリング」として。したがって、これは、たとえば最終ユーザーに表示される変更ログの一部であってはなりませんが、開発者の変更ログがある場合は、興味深いかもしれません。
  • 「api」でタグ付けして、APIの変更や新しいAPIの内容をマークすることもできます...
  • ...等...

できるだけ頻繁にユーザー（機能）をターゲットにしてコミットメッセージを作成してください。

example

これは、これらの情報を保存する方法を示す標準のgit log --onelineです::

* 5a39f73 fix: encoding issues with non-ascii chars.
* a60d77a new: pkg: added ``.travis.yml`` for automated tests. 
* 57129ba new: much greater performance on big repository by issuing only one Shell command for all the commits. (fixes #7)
* 6b4b267 chg: dev: refactored out the formatting characters from GIT.
* 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor 
* 6b891bc new: add utf-8 encoding declaration !minor

あなたが気づいたなら、私が選んだ形式は次のとおりです。

{new|chg|fix}: [{dev|pkg}:] COMMIT_MESSAGE [!{minor|refactor} ... ]

実際の出力結果を見るには、 gitchangelog のPyPIページの最後を見ることができます

私のコミットメッセージ規約の完全なドキュメントを参照するには、参照ファイル gitchangelog.rc.reference を参照してください。

これから絶妙な変更ログを生成する方法

その後、完全な変更ログを作成するのは非常に簡単です。非常に迅速に独自のスクリプトを作成するか、gitchangelogを使用できます。

gitchangelogは完全な変更ログを生成し（セクションサポートはNew、Fix...として）、独自のコミット規則に合わせて合理的に構成できます。 Mustache、Mako templatingによるテンプレートのおかげであらゆるタイプの出力をサポートし、raw pythonで記述されたデフォルトのレガシーエンジンを備えています。現在の3つのエンジンはすべて、それらの使用方法の例があり、gitchangelogのPyPIページに表示されるものとしてchangelogを出力できます。

他にもgit logからchangelogのツールがたくさんあることを知っていると思います。

52
vaab

ポイントCHANGELOGへの詳細。あなたはそれが好きかどうか教えてください。

git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B
24
Harshniket Seta

gitlog-to-changelog スクリプトは、GNUスタイルのChangeLogを生成するのに便利です。

gitlog-to-changelog --helpで示されているように、オプション--sinceを使用して、ChangeLogファイルの生成に使用するコミットを選択できます。

gitlog-to-changelog --since=2008-01-01 > ChangeLog

または、--の後に追加の引数を渡すことにより、git-logに渡されます（gitlog-to-changelogによって内部的に呼び出されます）。

gitlog-to-changelog -- -n 5 foo > last-5-commits-to-branch-foo

たとえば、プロジェクトのトップレベルのMakefile.amで次のルールを使用しています。

.PHONY: update-ChangeLog
update-ChangeLog:
    if test -d $(srcdir)/.git; then                         \
       $(srcdir)/build-aux/gitlog-to-changelog              \
          --format='%s%n%n%b%n' --no-cluster                \
          --strip-tab --strip-cherry-pick                   \
          -- $$(cat $(srcdir)/.last-cl-gen)..               \
        >ChangeLog.tmp                                      \
      && git rev-list -n 1 HEAD >.last-cl-gen.tmp           \
      && (echo; cat $(srcdir)/ChangeLog) >>ChangeLog.tmp    \
      && mv -f ChangeLog.tmp $(srcdir)/ChangeLog            \
      && mv -f .last-cl-gen.tmp $(srcdir)/.last-cl-gen      \
      && rm -f ChangeLog.tmp;                               \
    fi

EXTRA_DIST += .last-cl-gen

このルールは、リリース時にChangeLogを最新のまだ記録されていないコミットメッセージで更新するために使用されます。ファイル.last-cl-genには、ChangeLogに記録された最新のコミットのSHA1識別子が含まれ、Gitリポジトリに格納されます。 ChangeLogもリポジトリに記録されるため、コミットメッセージを変更せずに編集できます（入力ミスを修正するなど）。

22
Roland Levillain

バージョンごとにタグを作成することがベストプラクティスであるため、バージョンごとに変更ログをパーティションに分割することができます。その場合、このコマンドは次のことに役立ちます。

git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B
18
bithavoc

GitHubプロジェクトの場合：github-changelog-generator

タグのクローズされた問題から変更ログを生成し、プルリクエストをマージします。

このCHANGELOG.mdはこのスクリプトによって生成されました。

例：

変更履歴

1.2.5 （2015-01-15）

完全な変更ログ

実装された機能強化：

  • マイルストーンを使用して、どのバージョンのバグが修正されたかを指定します ＃22

修正されたバグ：

  • タグなしでレポのログを生成しようとしたときにエラーが発生しました ＃32

プルリクエストのマージ：

  • PrettyPrintクラスは小文字の 'pp'を使用して含まれています ＃4 （- schwing ）

  • コマンドラインオプションを介してエンタープライズgithubをサポート ＃42 （ glenlovett ）

14
skywinder

このためのライブラリも作成しました。 Mustacheテンプレートを使用して完全に構成可能です。ができる：

  • CHANGELOG.md のように、ファイルに保存されます。
  • MediaWiki に投稿する
  • または、STDOUTに印刷するだけです

私も作った：

Githubの詳細： https://github.com/tomasbjerre/git-changelog-lib

コマンドラインから：

npx git-changelog-command-line -std -tec "
# Changelog

Changelog for {{ownerName}} {{repoName}}.

{{#tags}}
## {{name}}
 {{#issues}}
  {{#hasIssue}}
   {{#hasLink}}
### {{name}} [{{issue}}]({{link}}) {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
   {{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
  {{/hasIssue}}
  {{^hasIssue}}
### {{name}}
  {{/hasIssue}}

  {{#commits}}
**{{{messageTitle}}}**

{{#messageBodyItems}}
 * {{.}} 
{{/messageBodyItems}}

[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*

  {{/commits}}

 {{/issues}}
{{/tags}}
"

またはジェンキンスで：

enter image description here

10
Tomas Bjerre
git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort

私が使用したいものです。最後のタグ以降のすべてのコミットを取得します。 cutはコミットハッシュを取り除きます。コミットメッセージの先頭でチケット番号を使用する場合、それらはsortでグループ化されます。ソートは、特定のコミットの前にfix、typoなどを付ける場合にも役立ちます。

3
orkoden

bithavoc に基づき、HEADまでlast tagをリストします。ただし、2つのタグ間のログを一覧表示したいと考えています。

// 2 or 3 dots between `YOUR_LAST_VERSION_TAG` and `HEAD`
git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

2つのタグ間のログをリストします。

// 2 or 3 dots between 2 tags
git log FROM_TAG...TO_TAG

たとえば、v1.0.0からv1.0.1までのログをリストします。

git log v1.0.0...v1.0.1 --oneline --decorate
2
AechoLiu

GNUスタイルのchangelog の場合、関数をクックしました

gnuc() {
  {
    printf "$(date "+%Y-%m-%d")  John Doe  <[email protected]>\n\n"
    git diff-tree --no-commit-id --name-only -r HEAD | sed 's/^/\t* /'
  } | tee /dev/tty | xsel -b
}

これとともに：

  • ChangeLogの最終編集を行う前に、定期的に変更をバックアップしてリベースするために変更をコミットします
  • 次に実行：gnuc

そして今、私のクリップボードには次のようなものが含まれています：

2015-07-24  John Doe  <[email protected]>

        * gdb/python/py-linetable.c (): .
        * gdb/python/py-symtab.c (): .

次に、クリップボードを開始点として使用して、ChangeLogを更新します。

それは完全ではありません（たとえば、ファイルはChangeLogパスに関連している必要があるため、python/py-symtab.cを編集するので、gdb/なしのgdb/ChangeLog）が、良い出発点です。

より高度なスクリプト：

ただし、Tromeyに同意する必要があります。ChangeLogでgitコミットデータを複製することは役に立ちません。

チェンジログを作成する場合は、おそらく http://keepachangelog.com/ で指定されているように、何が起こっているのかをsummaryにしてください。

1
Ciro Santilli 新疆改造中心996ICU六四事件

Release-filenameに日付が設定された新しいリリースごとに、CIサーバーがCHANGELOGという名前のファイルに以下をパイプします。

>git log --graph --all --date=relative --pretty=format:"%x09 %ad %d %s (%aN)"
1
Lorenz Lo Sauer