Question

我有一个Jenkins工作，执行以下步骤。

结帐发布分支
修改分支上的几个文件
在本地提交已修改的文件，但不要按
标记分支
签出代码
构建

从步骤 3 可以看出，修改后的文件不应该被推回到master，它们应该只存在于用于构建的标记上。

由于Git标签只是一个指向提交的指针，我必须在标记之前提交修改后的文件，但后来我不希望将修改后的文件推回原点。

修改后的文件应仅存在于构建的标记中。我想我的问题确实是，

我应该从发布分支中删除构建分支，修改文件，提交，标记分支，推送标记以及丢弃构建分支吗？

或者，

按照现有流程并恢复修改发布分支本地分支上的文件的提交，并推送它？

Answer 1

你不应该这样做。

如果它不是分支的一部分，则不应该使分支的提交部分。

在分支上进行提交，然后撤消它，这是不必要的复杂。它起作用，并给出正确的结果，但如果你能从一开始就做正确的事情，那么不要先做错事然后再修好。

相反，不要检查分支。查看分支指向的提交。如果您想使用分支名称签出，一种简单的方法是git checkout branch~0。这将为您留下一个独立的HEAD，不会附加到任何分支。然后，您可以修改文件，创建提交，标记并推送标记。

Answer 2

这肯定是你在那里的一个奇怪的过程。我知道您可能必须执行一些需要运行的预构建步骤才能成功构建所有内容，但这些更改必须提交并作为标记推送似乎很奇怪。如果您有此需求，则表明预构建过程会进行一些重大更改（您需要跟踪），因此您可能需要花一些时间来改进构建过程，以便不再需要这样做。 / p>

话虽如此，实际上还原了与构建相关的提交，因此影响正常历史似乎有点混乱。构建过程虽然很奇怪，但永远不应该影响正常的开发流程，并且在历史记录中添加提交（一个修补某个东西，一个修复相同的东西）确实听起来不是一个好主意。特别是因为理论上你可能遇到构建服务器推送这些提交并遇到冲突的情况 - 你不希望这样。

所以我会坚持按原样保留分支，并暂时添加预构建提交并为其提供标记。正如你所说的那样，标签只是提交的指针，而且分支实际上是相同的，当你有一个指向提交的标签时，没有必要为什么要影响分支。

基本上，构建过程需要做的是：

# update remote and reset to the current release
git fetch origin
git reset --hard origin/release

# pre-build patching

# add and commit
git commit -a -m 'Build 1234 from 2015-05-28'

# create tag
git tag -a build-1234 -m 'Build 1234 from 2015-05-28'

# push the tag (only!)
git push origin build-1234

# build and ship

请注意，我从不谈论那里的分支;你只是忽略了你就是一个人。当你更新它（作为git commit的一部分）时，你永远不会告诉任何人，只能直接推送标签。在下一个版本中（假设你没有完全抛弃每个版本的环境），你将从git reset --hard获得最新的更改，丢弃你的临时提交（该标记仍然指向它））。

Answer 3

假设您没有推送分支，您可以使用git rebase -i有选择地删除您不再需要的提交。只要标签存活，标签引用的提交就会存在。

如果您已推动分支，则只需git revert。恢复提交实际上会添加新的提交，旧的提交将保持不变。

Git - 如何在标记中保留更改，但还原已标记的分支中的更改？

3 个答案: