git：更新相互依赖的分支

Question

情况 我认为图片是更好的解释：

如您所见，我们有几个分支，其中大部分是solution-xyz-foo，用于不同的编号xyz。 solution-12 基于 solution-11 等等。这条规则也有一些偏差，例如分支hystrix-dashboard-demo.

动机 分支中的代码供课程参与者在课堂式课程中使用。因此，参与者解决了练习，并在课程结束时得到类似于我们在solution-24 分支中提供的代码。 如果参与者被赶超或面临其他问题，他可以轻松地检查相应的分支并继续其余的练习。

此外，还可以查看每个练习的解决方案，这些解决方案作为单个提交提供。

换句话说，对于课程参与者而言，建立在彼此之上的分支/解决方案具有我们希望保持的巨大优势（这是基于迄今为止举办的多门课程的反馈）。

作为课程的开发人员（准备练习和解决方案，向参与者展示内容等），我们需要不时更新部分代码。例如，我们可能想解决solution-3 中的问题。为了使这个修复在solution-4 等中可见，我们需要合并/rebase/cherry-pick 包含修复的提交。为了避免造成巨大的混乱，我们决定将每个解决方案的所有更新压缩到一个提交中，然后使用一些 rebase 重新构建图中所示的线性结构。

问题 正如您可能已经猜到的那样，做rebase 需要做很多工作。即使使用辅助脚本（在变基后将分支重新附加到提交，但需要在新/更改的分支名称的情况下进行维护），我们仍然需要进行变基，修复冲突，重新附加分支，并将更改推送回存储库（使用强制推送）。

除了涉及的实际工作之外，这是只有具有大量 git 经验的团队成员才有信心去做的事情。换句话说，那些没有那么自信的人会抱怨这个程序（我很清楚）。

附带说明，我们失去了 git 的明显优势：没有更改历史记录（旧版本丢失）。此外，开发人员需要协作并传达对代码的更改。

问题 您能推荐任何可以解决以下问题的标签/分支/rebase/... 工作流程吗？

• 课程参与者可以轻松查看他们当前正在进行的练习的最新解决方案（编辑：目前，在 Eclipse 中使用鼠标执行此操作是首选方式）
• 每个练习的解决方案都以方便的方式提供（即单次提交）
• 开发人员可以轻松地将修复和更新集成到各个解决方案中，以便后续基于它构建的解决方案也相应更新
• [可选] 保留更改历史记录

请注意，您可以假设在课程进行期间代码不会更改（因此参与者的计算机上不需要git remote update）。

Answer 1

不要将每个“solution-xyz-foo”提交作为单独的分支访问，而是尝试将其作为链中搜索的祖先提交进行访问。

git checkout -b MyWorkingBranch remotes/origin/LAST_COMMIT_IN_COURSE^\{/solution-xyz\}

然后'rebase --onto IMPROVED_COMMIT' 之后的结帐将根据 IMPROVED_COMMIT 生成分支

见

git help revisions

如果你使用标签而不是分支，你可以使用

git filter-branch --tag-name-filter <rename command>

更新引用所有已更改提交的所有标签。请参阅“git help filter-branch”。再次，学生可以使用 'git checkout -b TAGNAME' 直接从标签名称中获取分支，并且可以使用历史记录。

Answer 2

因此，这听起来像是在链中间进行手术变基以修复某些提交，然后是（以前）后续提交的另一个变基——到新修复的提交上。所以我对评论“......即使使用帮助脚本（在变基后将分支重新附加到提交，但在新/更改分支名称的情况下需要维护）......”感到困惑。这似乎（可能）和 rebase 一样简单——在你更新的提交上，所以不需要为新的/更改的分支名称维护它——所有这些东西都是通过 rebase 进行的，不是吗？