Question

我在git中有一个项目，其中所有内容都直接在master分支上完成，标记用于标记已发布的代码版本。我知道这不是理想的，并且一直在研究这样的git流：http://nvie.com/posts/a-successful-git-branching-model/ - 但是，即使使用更好的设置，我也不能轻易看到“修补程序”可能是一种方式应用于项目的先前版本并提交回主分支......

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

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

提交C被标记为发布点，例如“v0.2”，我想改变那个代码库。我可以将refs / tags / v0.2签出到一个新的本地分支并提交一个文件的更改（例如本例中的Main.java），甚至标记提交（Commit H标记为'v0.3'）

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

但实际上，我不希望每个版本都有一个分支 - 我只想在主分支上找到相关的标签。将提交H标记为'v0.3'，如果我尝试删除分支'v0.2'，我得到：

'错误：分支'v2'未完全合并。如果你确定你想要的话删除它，运行'git branch -D v2'

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

我想我仍然可以删除带有'-D'的分支而不会丢失提交，因为提交仍然被标记引用。

在临时仓库中执行此操作，然后从主分支运行'git log --graph --all'向我展示：

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

如果我保留上述历史记录，可能会遇到哪些问题？如果没有，可以有人建议采用最佳实践方法来处理这种情况吗？

我希望我不要过度思考这个:-)任何建议都非常感激。

Answer 1

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

不。

我想我仍然可以删除带有'-D'的分支而不会丢失提交，因为提交仍然被标记引用。

右。完全正确。

如果我保留上述历史记录，可能会遇到哪些问题？

如果您在叶子提交中所需的更改已经存在于主线中，或者不再相关，则根本不存在。

此外，如果您可能因某些原因需要复苏的每个提交都可以从某个仓库中的引用访问，您可以在需要时进行，但不会丢失任何内容。没有什么说每个回购都必须有所有的承诺（你没有推动你的所有分支，对吗？没有人需要看到你的wip东西或你的实验或只是简单的放屁。）

检查商店规则。行政程序可能有其他问题而不是未来的发展需求。

我无法轻易看到“修补程序”可以应用于项目的先前版本并提交回主分支的方式......

始终工作（如，总是留下完全正确的历史记录）选项是，分支最早的合并提交引入错误，修复它，将其合并到具有错误提交的每个分支提示。对这些更改的后续更改可能与修复冲突，如果对受影响的文件进行了大量工作，您可能希望检查即使是显而易见的成功合并，也不会免除基于文本的vcs。

Answer 2

问题在于你有两个版本，I和H.H的变化不会进入最新版本，或者，如果你用H构建代码，你就不会有D..G和I的变化。

如果您想要同时进行更改，可以合并它们。

当然，如果您将H的更改应用到主服务器，那么这不是问题。你基本上手工完成了合并本来会做的事情。您可以继续构建新版本。但是，拥有这个晃来晃去的分支看起来很奇怪而且令人困惑，如果我是你，我会合并它以解决这个问题。

所以你不 删除或合并它，但我会，而且我认为这是常见的做法。

Answer 3

您对Commit H有什么看法？这是个问题。它应该在Commit C和Commit D之间吗？然后，您可以尝试git rebase -i HEAD~7或git rebase -i <VersionC>并提交您的提交。但是，如果没有其他人使用相同的主分支，您将被禁止或解雇。它应该落后于承诺吗？然后你可以（有点脏）做git rebase <CommitI>，解决冲突并把它作为最新版本。

那么，明确一下：在哪种情况下谁需要承诺？它是否应该影响CommitI或G？其他人是否阅读了存储库？

Git：将一个新提交合并回master，这是针对一个非常旧的提交

3 个答案: