Using git tag to save the state of the repository -

i have been doing reading git tags , think little confused in head. see tags can used commit. so, assume here whats happening in repo.,

commit - c1 commit - c2 commit - c3 commit - c4 commit - c5

at time, 5 commits made repo. if run git tag -a tagv1.0 -m "first tag", creates tag saves current state of repo, right? files in @ moment of running command, not files in commit c5. snapshot of repo @ moment of running command?

after created tag. commit - c6 came in. if git tag -a -f tagv1.0 -m "updating tag". includes commits , c6 well. right?

after created tag, if commit 6,7,8 came in. can force update tag include 7 , not 6 , 8?

thanks looking.

a tag not, itself, save state of repository. in fact, not save @ all,^1,3 unless consider "jotting down sha-1 of current commit" "saving" something:

$ git rev-parse head d1574b852963482d4b482992ad6343691082412f 

the 40-character "number" above current commit. git tag write file somewhere.²

to understand this, need know:

• every commit "forever".³ "true name", big ugly sha-1, uniquely identifies commit, , only commit. sha-1 crypographic checksum of contents of commit, including time stamps when commit made, author name , email, , on.
• each commit includes raw sha-1 of parent commit(s). how, starting commit c5, git can find c4: c5 contains true name of c4, part of c5's own contents. c4 lets git find c3, , on.
• as far git concerned, reference name—the major obvious ones branch , tag names, there lots of other forms of references—is way come starting sha-1.

when (or git) stores 1 of these sha-1 true-names inside various items—repository objects commits, or files named according tag or branch name, or whatever—we "points to" object true-name store. c5 points c4, , c4 points c3, , on.

thus, if have tag pointing c5, , create new commits in repository, tag still points c5.⁴ if want make point somewhere else—such new commit c6—you must delete old 1 , make new 1 (or, really, overwrite contents of file, long it's in own private file , not shared packed refs in footnote 2).

---

¹this not entirely true: annotated tag saves annotation in repository, , has corresponding lightweight tag point newly-saved object. annotated tag in repository has own sha-1, , contains, part of annotation, sha-1 of whatever you're tagging.

²the file .git/refs/tags/tagname, can "packed" , moved .git/packed-refs along other references.

³well, almost. commit, or indeed git repository object, no incoming references eligible garbage collection. means each reference 2 things: give name raw sha-1, and—at least potentially—protect object sha-1 names, saving grim collector. in particular sense, tag said "save" things—but typically, tag name one way reach commit. instance, after make c6, can reach c5 starting branch name , moving parent; that's sufficient protect c5.

⁴this should make stop , wonder: hey, wait, how branch automatically include new commit c6 once make it? answer is: git automatically deletes , re-creates it, part of process of making commit c6. that's makes branch name special: can tell git "get on branch", git writing branch name down somewhere,⁵ , when make new commits, git sees you're on branch , automatically updates reference-file.

⁵specifically, writes current branch name in file .git/head. git rev-parse head, shown above, reads head file, finds names branch, , reads branch file, , git has raw sha-1 "true name" current commit. or, if ask git branch you're on, reads head file, finds names branch, , stops there , prints out branch name.