我们使用git来管理我们的项目,我们为每个项目都有一个分支: dev分期生产。
我想使用git标签来管理软件的版本。据我所知,如果我在一个分支上并添加了几个提交,那么我必须运行: git标记1.0
用我们要达到的版本号重新调整1.0,然后我可以使用: git推送原点1.0来推送标签。
我可以用: git推送标签更新分支。
但是,现在如何重用标记呢?如果我将更多的代码提交到我的本地存储库,并希望它很容易成为1.0版本呢?或者你只是添加了一个像1.1这样的新标签?
此外,如果我的同事在他的本地存储库中使用相同的标记名,并且我们都将同一标记的代码推上,会发生什么情况?
最后,如果我们不小心推送代码而不运行git标记来标记提交,会发生什么情况。
我不太明白标签是如何工作的,我想它们的工作方式就像你会给博客贴上标签一样--你可以用相同的标签标记很多不同的提交,然后重复使用标签等等,就像我想的一个分支。
发布于 2010-10-15 17:56:15
但是,现在如何重用标记呢?如果我将更多的代码提交到我的本地存储库,并希望它很容易成为1.0版本呢?或者你只是添加了一个像1.1这样的新标签?
您可以使用git tag -d 1.0删除标记,然后使用git push origin :refs/tags/1.0在服务器上删除它。
但最佳实践是只发布标记,然后在创建标记的地方为该版本创建维护分支。在该分支上,您推送修补程序,并使用1.1、1.2、.当你发布最新版本的时候。在将代码交给客户之后移动标记是一种糟糕的做法。
此外,如果我的同事在他的本地存储库中使用相同的标记名,并且我们都将同一标记的代码推上,会发生什么情况?
我很肯定你们中第二个推标签的人会收到一个错误。你自己试试,看看会发生什么:
git checkout -b testbranch
git tag test1
git push origin tag test1
git tag -d test1
touch testfile
git add testfile
git commit -m "Added testfile"
git push origin testbranch
git tag test1
git push origin tag test1最后,如果我们不小心推送代码而不运行git标记来标记提交,会发生什么情况。
在按下提交之后,应该按下标记。您不能同时执行这两项操作(git push --tags不推送提交,只执行标记)。如果您首先推送标签,遥控器将有悬空的引用,直到您推送提交。所以你应该去做
git push origin master
git push origin --tags或者类似的,视你的情况而定。
我不太明白标签是如何工作的,我想它们的工作方式就像你会给博客贴上标签一样--你可以用相同的标签标记很多不同的提交,然后重复使用标签等等,就像我想的一个分支。
标签就像提交上的标签,所以你可以将一些提交标记为“特殊”。最常见的情况是,这用于标记发布,因此如果客户报告错误,则始终可以返回并查看该版本中的确切内容。
发布于 2017-10-06 15:28:19
简单地回答标题问题,我想出了一个半专业的解决方案(可能对某些人有用),它会自动用我所指向的git版本标记标记我的代码,这样我就不必(记得)在每次构建时手动更新版本号。我目前在一个小组中工作(< 5个开发人员),我们的配置管理仍在进行中。但在成熟之前,这是一个适合我的解决方案。
高级别视图,以下是步骤:
#define是提取的版本及其部件.#include的这个头文件(它不是存储库的一部分)和瞧,版本是自动包括在没有任何手动输入从我。更详细的是:
剧本
我目前使用的是一个3位版本控制方案,major.minor.build,其中构建可能是一个字符串(例如,v1.8.3b)。注意,使用echo -e打印换行符对我有用,但可能是是更好的选择。
# queries git for the version tag I'm currently pointed at. Throughout SO there
# are different versions of this command, but this one works for me. And in fact
# all my tags are annotated, so I could just use "git describe"
VERSION=`git describe --tags`
# replace all the '.' with ' ', then split the array based on the spaces.
# Obviously this will have its limitations if there are spaces in your
# version tag, or maybe even wildcard characters, but that should never
# be the case for me
VER_ARRAY=(${VERSION//./ })
# pull out the major, minor, and build components. These can be used to
# pre-processor check different versions of my code for certain compatibility,
# should the need arise
V_MAJOR=${VER_ARRAY[0]}
V_MINOR=$(VER_ARRAY[1]}
V_BUILD=${VER_ARRAY[2]}
# all of my build tags are preceded by a 'v', so remove that simply by taking
# the substring starting at position 1
V_MAJOR=${V_MAJOR:1}
# define the path and header file
VERSION_HEADER=./path/to/codeVer.h
# write these to file. > creates the file and >> appends to the file
echo -e "// Auto-generated version header on " `date` "\n\n" > $VERSION_HEADER
echo -e "#define MY_CODE_VERSION \""$VERSION"\"\n\n" >> $VERSION_HEADER
echo -e "#define MY_CODE_MAJOR "$V_MAJOR >> $VERSION_HEADER
echo -e "#define MY_CODE_MINOR "$V_MINOR >> $VERSION_HEADER
echo -e "#define MY_CODE_BUILD \""$V_BUILD"\"\n\n" >> $VERSION_HEADER马基夫
在我的makefile顶部,我有$(shell ./genVer.sh)。这告诉make要运行shell命令,./genVer.sh是脚本的路径和名称。一个更好的方法是为脚本设置一个.PHONY目标,然后把这个目标作为相关目标的先决条件,但是我有很多目标,这是一个一条龙捕获。
密码
现在,在所有相关的源文件/头文件中,我只需
#include "codeVer.h"
....
#ifndef MY_CODE_VERSION
// although if codeVer.h cannot be found we will get a fatal error before
// this warning
#warning "Unable to find code version, defaulting to v0.0.0"
#define MY_CODE_VERSION "v0.0.0"
#endif现在,每当我make时,都会提取当前版本,生成标头,我的代码#include的文件,并且我得到正确的版本号而不做任何手工操作。注意,这不仅适用于最新的版本,如果您签出一个旧的标记,这也会起作用(当然,如果在该版本中实现了这些更改)。
这确实有它的缺点。最显著的
codeVer.h添加到.gitignore列表中,因为我不希望在回购中跟踪它。这意味着您可能会将您的代码交给缺少此文件的人,而他们将不知道它是什么版本。但是如果他们使用的是git (就像他们应该做的那样!)而且他们git pull/clone你的东西,所有的标签都会随它而来。make clean也会生成这个文件(这似乎违反了直觉),但是如果您使用了正确的方法并使用了上面描述的.PHONY目标,那就不是问题了。发布于 2010-10-14 05:04:36
标记信息的一个很好的资源是在gitref.org上
不要试图重用版本号。最好是只到1.1或1.0a。在手册页中详细讨论了这一点。
关于你的问题:
最后,如果我们意外地推送代码而没有运行git标记来标记提交,会发生什么情况?
您可以通过在命令中放置commit ref来标记旧提交:
git tag 1.1 HEAD~3https://stackoverflow.com/questions/3929975
复制相似问题