The answer to Can I add metadata to git commits? Or can I hide some tags in gitk mentions git n开发者_如何学Pythonotes as a way to add metadata to a git commit.
Is git notes, possibly taking advantage of its namespace functionality in case I want to add other types of notes, the best way to categorize commits? For example, I'd like to categorize commits into "refactoring", "change-functionality", "bug-fix", "bug-introduce", and be able to ask git to only list commits that are in certain categories.
What you are proposing is quite similar to what the ruby-based gem "step-up" is doing, based on git notes
.
The great goal of this Gem is giving to developers an easy way to manage these notes.
With a culture of notating all the relevant developments, its possible to retrieve a summary of a range of versions besides that specifying what kind of information will be retrieved.
For example, imagine that you want to see all the features implemented in your application since the version v1.10.1 up to v2.0.0
stepup notes --since v1.10.1 upto v2.0.0 --sections pre_deploy pos_deploy
The result would be something like the following:
Showing notes since v1.10.1 up to v2.0.0 (including notes of tags: v1.10.1, v1.10.2, v1.51.0, v2.0.0)
---
Pre-Deploy:
- dependency of version v10 of project XYZ
- it needed to rename the following file
- config/environment_variables.yml.sample -> config/environment_variables.yml
- rake articles:index
Pos-Deploy:
- Reindex articles
- rake articles:index
- rake db:seed
- rake categories:reload
ranged_notes.rb
will define functions to get all the relevant commits, based on their notes.
git.rb
contains the actual git notes
commands.
I don’t know what the intentions of the original authors of git-notes(1) were. But I would personally say no.
git-notes(1) is for adding mutable metadata to commits. So sure, if the categories are mutable (e.g. you might want to add categories a while after a commit has been made and you don’t want to change that commit) then git-notes(1) might be useful. But why use multiple namespaces? Why not store them under one namespace? A category (I imagine) is just a keyword, and you can easily append simple strings to a note. So you might end up with something like this for a note:
bug fix
breaking change
refactor
After doing:
git notes --ref=yourref --append -m 'bug fix'
git notes --ref=yourref --append -m 'breaking change'
git notes --ref=yourref --append -m 'refactor'
But if you just need immutable metadata (i.e. you know what categories you want when writing the commit) then it’s simpler to just add the categories to your commit message:
Big change #4564
Keywords: breaking change, refactor, bugfix
I’ve used the name “Keywords” here.
This might be a log:
$ git log --patch
commit 498cc43746aa89a0bb335781eb8157908da12532 (HEAD -> master)
Author: Victor Version Control <vvc@vcs.org>
Date: Fri Sep 24 21:01:47 2021 +0200
Set the scene
Keywords: worldbuilding
diff --git a/novel.md b/novel.md
index 8bf53766294f..999578522b1f 100644
--- a/novel.md
+++ b/novel.md
@@ -1 +1,4 @@
Once upon a time there was an ogre.
+
+He lived in an ogre village in South-Okranazoa, the highlands west of
+the lowlands and plains of Kzherbadai.
commit b307a1c02eec479888cba7676e00903071fb0878
Author: Victor Version Control <vvc@vcs.org>
Date: Fri Sep 24 20:59:46 2021 +0200
Start the story
Keywords: intro, ogrekin
diff --git a/novel.md b/novel.md
new file mode 100644
index 000000000000..8bf53766294f
--- /dev/null
+++ b/novel.md
@@ -0,0 +1 @@
+Once upon a time there was an ogre.
If you want to filter the log on certain keywords then you can use this crude and somewhat wrong MVP:
$ git log --grep='Keywords:.*ogrekin'
commit b307a1c02eec479888cba7676e00903071fb0878
Author: Victor Version Control <vvc@vcs.org>
Date: Fri Sep 24 20:59:46 2021 +0200
Start the story
Keywords: intro, ogrekin
精彩评论