I want the tag to be used only for the release branch in bitbucket pipeline. My idea is to find the branch name by tag or commit and then check it.

But this repository is obtained by tag in pipeline.

git clone --branch="{tag_name}" {repository_address}
git reset --hard {commit_num}

In this scenario, there is no branch.

$ git branch
* (no branch)

I've tried every way but can't get the corresponding branch name by the tag or the commit.

There are several branches via git branch -r --contains {commit_num}. And I don't know which is the specific branch that corresponds to.

I'm confused. Is my usage or idea wrong?

CodePudding user response：

The git clone command, by default, copies all the commits and none of the branches.¹ Then it creates one branch, the one you specify with -b.² If you specify a tag with -b, it creates no branches and just checks out the commit specified by the tag.

Each of the names that the other Git repository had as a branch name are now remote-tracking names in your repository. They are listed under git branch -r output, or with git for-each-ref refs/remotes.

There are several branches via git branch -r --contains {commit_num}. And I don't know which is the specific branch that corresponds to.

It corresponds to all of those branches. A commit is often in many branches at the same time. This is one of many reasons that branch names don't actually matter, in Git. What really matters is the hash ID. It's just that humans like to use branch names to find hash IDs, and Git accommodates us.

(If you can find a commit by a tag name, there's no need for that commit to be on any branch. Some commits, such as those made by git stash, are normally on no branch either. The hash ID is all that really matters. But if you can't find the hash ID, you can't even tell if you have the commit, and since we use names—branch names, tag names, "the stash", etc—to find the hash IDs of some commits, then use those commits to find more commits, you'll need some name that finds some commit that finds a commit that finds a commit that finds the commit you care about, unless you've memorized the hash ID.)

¹Technically, it copies only "reachable" commits, as sent by the Git software at the repository you're cloning. But in practice that's pretty much all the commits.

²If you leave out the -b option, your Git software asks the other repository's Git software which branch name they recommend, and uses that name as the -b argument.

CodePudding user response：

I am afraid your idea is wrong. There is no one-to-one mapping for branches and commits. Think about the initial commit of your repo: all branches contain it!

If you want to keep developing on a release series, it is somewhat conventional to have a branch named after the major.minor version of its tags and keep it active even after higher releases have been made, e.g. to backport security fixes. This way you would simply clone the branch for the X.Y series, not the vX.Y.Z tag.

Remember that latest releases will probably contain most of the past tags. E.g a 3.0 branch will only not contain the v2.X.Y tags that were made after the 3.0 branch forked from the 2.X.