Git:将一个新的提交 merge 回 master，这是针对一个非常旧的提交

Question

我在 git 中有一个项目，所有的事情都直接在 master 分支上完成，标签被用来标记代码的发布版本。我知道这并不理想，并且一直在查看 git 流程，例如:http://nvie.com/posts/a-successful-git-branching-model/ - 然而，即使使用更好的设置，我也无法轻易地看到可以将“修补程序”应用于项目的先前版本并提交回主分支的方法...

我正在使用的 git 存储库有一个远程源，目前只有我自己和其他开发人员有它的克隆。主分支日志现在看起来像这样:

master: A--B--(C)--...--F--G

提交 C 被标记为发布点，例如“v0.2”，我想更改该代码库。我可以将 refs/tags/v0.2 check out 到一个新的本地分支并提交对文件的更改(例如本例中的 Main.java)，甚至标记该提交(提交 H 标记为“v0.3”)

master: A--B--(C)--D--...--F--G
v0.2  :        C--(H)

但实际上，我不想让每个版本都有一个分支——我只想要主分支上的相关标签。将提交 H 标记为“v0.3”后，如果我尝试删除分支“v0.2”，我会得到:

'error: The branch 'v2' is not fully merged. If you are sure you want to delete it, run 'git branch -D v2'

好的，所以它没有 merge 回 master，但是 Main.java 的编辑部分在最新版本中甚至不再存在，所以这是一个问题吗？

我想我仍然可以使用“-D”删除分支并且不会丢失提交，因为提交仍然被标记引用。

在临时存储库上执行此操作，然后从 master 分支运行“git log --graph --all”显示:

* Commit I
|
* Commit G
...
|
* Commit D
|
|  * Commit H
|/
* Commit C
...
|
* Commit A

如上留下历史会遇到什么问题？如果没有，有人可以建议处理这种情况的最佳实践方法吗？

我希望我没有想太多 :-) 非常感谢任何建议。

Answer 1

Okay, so it's not merged back to master but the edited part of Main.java doesn't even exist any more in the latest version, so is this a problem?

没有。

I think I can still delete the branch with '-D' and not lose the commit because the commit is still referenced by a tag.

没错。完全正确。

What problems might I encounter if I leave the history as above?

如果您需要从叶提交中进行的更改已经存在于主线中，或者不再相关，则根本没有。

此外，如果您出于某种原因可能想要恢复的每个提交都可以从某个存储库中的引用访问，您可以在需要时访问它，那么什么都不会丢失。没有人说每个 repo 都必须有每个提交(你不会推送你所有的分支，对吧？没有人需要看到你的 wip 东西或你的实验或者只是简单地放屁)。

不过，请检查商店规则。除了 future 的发展需要，行政程序可能还有其他问题。

I can't easily see a way that a 'hotfix' could be applied to an previous release of the project and committed back to the master branch...

始终有效(例如，总是留下完全正确的历史记录)选项是，从最早引入错误的 merge 提交分支，在那里修复它，将其 merge 到每个有错误提交的分支提示。对这些内容的后续更改可能会与修复冲突，如果对受影响的文件进行了大量工作，您可能想要检查即使是明显成功的 merge ，没有任何基于文本的 vc 可以幸免。