- Our writer decides that she doesn't need to keep enhancing the vocabulary of
the first chapter (at least for now), so she proceeds to delete the branch
(
--decorate is required to show the tags if the output is pipelined)
git log --graph --oneline --decorate \
| grep "Replaced struggling and shore." -C 9999
git branch -d vocabulary-chapter-01
git branch
- After applying the
-d, commits don't belong to vocabulary-chapter-01, as the
branch doesn't exists anymore:
git log --graph --oneline --decorate \
| grep "Replaced struggling and shore." -C 9999
Finally, Alice marks the commit pointed by *HEAD* as the first version of the book with a tag
- This fact is reflected in the log:
git log --oneline --graph --decorate \
| grep v1 -C 9999
- And it is stored internally as another type of ref:
- In fact, a simple tag is just a pointer to a commit:
cat .git/refs/tags/v1
cat .git/refs/heads/main # points to the same object than the tag
Ouch: Alice realizes that she used a **lightweight tag**, but she would like to set a comment.
So she deletes the previously created tag:
- The tag reference has disappeared, and the directory is empty:
Alice wants to explain why this particular commit is important, and to be able
to append a comment to a tag, she needs to an *annotated* one. So whe will use
some extra flags with the `tag` command:
git tag -█ v1 -m "First chapter is ready to be reviewed!"
git tag -a v1 -m "First chapter is ready to be reviewed!"
- The newly created tag is actually a full object in the repository, so the value
of the reference doesn't point to the HEAD commit anymore:
ls .git/refs/tags
cat .git/refs/heads/main
cat .git/refs/tags/v1 # the tag ref points to a tag object, so doesn't match the last commit
- Alice is very proud of her work, and closes the laptop to get some fresh air and inspiration
