将git分支转换为git标签 [英] converting git branch to git tag

问题描述

我正在寻找将git分支转换为git标签的最好和最安全的方法。当我手动移植一个svn仓库时，我基本上复制了所有的分支机构，并且我们为每个次要版本（1.1,1.2,1.3）都有一个分支，尽管这样做可能并不是最好的方式，但是为了速度，当时我比标签更适合分支。我现在有分支机构1.5,1.6,1.7,1.8，但是由于我们在任何时候都只部署了1个版本的代码，我可能只需要最后一个版本就可以成为分支机构，被部署。所以我正在寻找将git分支转换为git标签的最佳方式。我认为我有一种方法，但确定它有多好。

到目前为止，我所做的每个分支都是要转换为标记的，我已经检查过为了确保那些不在主分支中的分支没有提交，所以我做了：

pre $ g $ log 1.5 ^ master
git log 1.6 ^ master
git log 1.7 ^ master

所有这些没有给我任何回报，我相信这意味着这些分支中的所有提交都存在于主控中。我这样做是因为我假定在那些不在master的分支中有提交，当将分支转换为标签时，我会失去它们，因为标签只是一个提交而不是开发线的指针。看起来不错，我的假设是，我只需要做：

  git tag 1.5v 1.5 
 git标签1.6v 1.6 
 git tag 1.7v 1.7 
  

然后我只需要删除在本地分支并将这些更改推送到远程存储库。这是将git分支转换为git标签的最佳方式吗？

另外一个问题是如果有人从1.7开始创建分支（这是没有人应该做的），并且他们拉取那些删除那个分支的变化，他们能够将这些变化合并到另一个分支（比如master）还是会破坏他们创建的分支？这是一个不应该发生的情况，因为除了最后一个版本之外，不应该创建任何人的分支版本（在本例中为1.8），但人们并不总是遵循程序，所以我想确保有一种方法要解决这个问题，如果发生了。

解决方案

简短回答：这不是问题。尽管我建议您使用 -m 选项创建带注释的带注释的标签（请参阅 man git -tag ），因为这将创建一个第一类标记，该标记将被 git describe 等使用，无需其他参数。

长答案：
远程分支不会直接影响本地分支。如果我从分支中创建分支或从公共回购中创建标签，那么当您删除该分支并获取回购时，我会看到您的分支已经消失，但我的分支在我的回购中仍然完整。

在您提交HEAD和您正在处理的分支指向新提交时，Brances只是git仓库中提交的符号名称。标签也是一个提交的符号名称，但是这是不可改变的（虽然你可以删除它但不能改变），所以它指向历史中的一个固定位置，而分支指向移动的头部历史上的一条线。由于git中的提交有零个，一个或多个父提交（初始提交为零，一个用于正常提交，多于一个用于合并），即使原始分支或标记从远程删除，您的本地回购仍然有一个指向你本地的分支，从这里你可以找到一个共同的祖先（假设分支是相关的），所以你仍然可以将任何分支的变化合并为主。

从svn到git起初可能有点混乱。听起来你还在用svn术语思考，使得一切都变得更加混乱。如果你把git看作高级文件系统（这就是Linus Torvalds编写它时），而不是源代码控制工具，我认为它更容易。我还建议你花一些时间阅读（或浏览） git给计算机科学家 a>，听起来并不令人望而生畏;并且更好地理解其实际工作方式将有助于您思考正确的方式。 ;）

I am looking for the best and safest way to convert a git branch to a git tag. When porting over a svn repository by hand, I basically copied over all our branches and we had a branch for each minor release (1.1, 1.2, 1.3) which in all honesty probably was not the best way of doing that but for the sake of speed, I was more comfortable with branches than tags at the time. I now have branches 1.5, 1.6, 1.7, 1.8 however since we only ever have 1 version of the code deployed at any given time, I probably only need the last version to be a branch incase any hot fixes need to go into that version that is deployed. So I am looking for the best way to convert a git branch to a git tag. I think I have a way but done sure how good it is.

What I have done so far is for each branch I want to convert to a tag, I have checked to make sure there are no commits in those branches that are not in the master branch, so I did:

git log 1.5 ^master
git log 1.6 ^master
git log 1.7 ^master

All of these return me nothing which I believe means all of the commits in those branches exist in master. I did this because I assumed if there were commits in those branches that were not in master, I would lose them when converting the branch to a tag as a tag is just a "pointer" to one commit and not a development line. With that seeming good, my assumption is that I would just have to do:

git tag 1.5v 1.5
git tag 1.6v 1.6
git tag 1.7v 1.7

Then I would just have to delete the branches locally and push those changes to the remote repository. Is this the best way of converting a git branch to a git tag?

Also one concern I have is if someone created a branch from say 1.7 (which no one should of) and they pull the changes that delete that branch, would they be able to merge those changes into another branch (say master) or would that kind of break the branch they created? This is a case that should not happen since no one should be created branches off of any branch version other than the version last one, in this case 1.8, but people do not always following procedure properly so I want to make sure there is a way to fix this if it happens.

解决方案

Short answer: it's not a problem. And creating tags the way you propose is okay, although I suggest you use the -m option to create an annotated tag with a comment (see man git-tag), as this will create a "first class" tag that will be used by git describe etc. without additional arguments.

Long answer: Remote branches will not affect the local branches directly. If I create a branch from a branch or a tag from your public repo, when you delete that branch, and I fetch your repo, I will see that your branch is gone, but my branch is still complete in my repo.

Brances are only symbolic names for the a commit in a git repo, when you commit the HEAD and the branch you're working on points to the new commit. A tag is also a symbolic name for a commit, but this is not changeable (you can delete it, though, but it cannot be changed), so it points to a fixed location in the history, while a branch point to the moving head of one line in the history. Since commits in git have zero, one or more parent commits (zero for initial commit, one for a normal commit, more than one for a merge), even if the original branch or tag is deleted from the remote your local repo still have a pointer to you local branch and from this you can find a common ancestor (assuming the branches are related in the first place), so you can still merge in changes done to any of your branches into master.

Coming from svn to git can be a bit confusing at first. It sounds like you're still thinking in svn terms, making everything more confusing. I think it's easier if you think of git more as an advanced filesystem (which is what Linus Torvalds were when he wrote it), instead of a source control tool. I also suggest you take some time to read (or skim through) git for computer scientists, it's not as daunting as it sounds; and having a better understanding of how it actually works will help you thinking the "correct way". ;)

这篇关于将git分支转换为git标签的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！