Hello. I have a certain misunderstanding of tags in Git. I will describe the situation. There is a certain project Project. I commit, push with a tag 1.0. I add to packagist, everything is perfectly displayed dev-master, 1.0. I wanted to make some changes to version 1.0. The tag has already been created, I make a new commit and push, but all changes are made to the dev-master. Why is that? Thank you in advance.

  • one
    Because tags are not branches and sit where they are created. - D-side

1 answer 1

A tag is just a named commit. If you need to support multiple versions make branches. That is, in your case, make a branch starting with tag 1.0 there and make edits for this version.

Update

Since the tag is just the name of a commit, you will not make any changes to it. And which branch to commit and how to organize is up to you. Here, for example, the beginning of the list of branches from scrapy turnips:

  remotes/origin/0.12 remotes/origin/0.14 remotes/origin/0.16 remotes/origin/0.18 remotes/origin/0.20 remotes/origin/0.22 remotes/origin/0.24 remotes/origin/1.0 remotes/origin/1.1 remotes/origin/HEAD -> origin/master

That is, they lead each version in their branch.

  • And when we add a dependency to the require section, for example, require: {"project": 1.0} 1.0 - what does it correspond to? Branch? Tag? Tag in the main branch? - Tapakan
  • And when will version 1.1 again create a branch? If you take popular repositories, for example, Yii2 they are all organized tags. That is, they before the push create a tag with a new version and make a push? And further, if any changes are made, they will already be in the new version. I understood correctly? - Tapakan
  • And when we add dependencies to the require section, for example, require: {"project": 1.0} 1.0 - Where does the version come from? Where it can be changed, so packagist would know. And that would establish the last stable. There was no need to write "regular expressions" in version - ^ 1.0-dev A - 1.0 or 1.1 or 1.1.2 - Tapakan