[dev_snd]

I think that the bigger problem is the misuse of Tags as the sole method of marking a commit for release for example.

Tags could be utilised for naming commits which would make it much easier to reason about where in the process of your development you are instead of referencing commits by hash. Hashes are hard to remember after all.

[WorldMaker]

Mutable names should be branches, in my opinion, but not because I think tags are only for releases. I will absolutely use local-only "light weight" tags to name immutable points in time that look nothing like releases (and try not to push them accidentally; this is something that I think git's UI could be better about, it's an expected pattern which is why `git push --tags` or `git push --follow-tags` is a separate action by default from normal push, but `git push --tags` which is mostly all-or-none is much more convenient than patterns that push individual, specific tags). I just feel strongly if it is a mutable reference point it needs to be a branch.

Branches are so cheap in git that there's little to no reason to not use a million branches to name every step in a process if you need to, and yeah if you need a long-term name for a specific commit local-only lightweight tags are handy for that. (I find lightweight versus annotated an often easy enough distinction between tags intended for local development and tags intended for release markers. This also seems to be intentional in git UX because of the way `git describe` by default skips lightweight tags.)

[bornfreddy]

Except, if you rebase, your tags get "lost" (not really, but they still point to the same old commit unless explicitly changed). Log is your friend, and making sure that the commits make sense (they do a single well-defined thing) helps a lot, because you always know which commit does what. But yes, that means using `git commit --fixup <commit id> && git -i --autosquash <commit id>^1` frequently to fix existing (older) commits instead of making new trivial ones.

[airtonix]

why are you rebasing a branch that has tags?

in my opinion (the one where i don't care what anyone else thinks kind) you shouldn't be using tags on your working branches and your mainline/release branches should only be the ones where tags exists.

This then means that the only place you should be rebasing is your working/feature/pr branches and that when you merge your working/feature/pr branch, it should get squashed into the target branch... No one cares about your fifty gazillion 'wip' commits.

[chrisdirkis]

I guess that's the parent's annoyance. It'd be nice to be able to use something like tags or labels for other things than releases, but since they're commit referents, they're pretty much only useful for releases and nothing else.

[bornfreddy]

I was responding to GPs idea to "name" commits with tags, so you've taken my comment out of context.

[juped]

This is called a branch in Git.

[viraptor]

Why not use branches for that? That's often for people to it.