git:更新相互依赖的分支。

Question

我认为图片是一个更好的解释：

​

​

正如您所看到的，我们有几个分支，其中大多数是solution-xyz-foo，用于表示不同的数字xyz。solution-12构建在solution-11上，等等。也有一些偏离这一规则，例如分支hystrix-dashboard-demo。

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

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

换句话说，对于课程参与者来说，建立在彼此之上的分支/解决方案提供了我们想要保持的巨大优势(这是建立在对迄今举办的多门课程的反馈基础上的)。

作为课程的开发人员(准备练习和解决方案，向参与者介绍内容等)我们需要不时地更新部分代码。例如，我们可能希望修复solution-3中的一个问题。为了使这个修复在solution-4等中可见，我们需要合并/重基/樱桃-选择包含修复的提交。为了避免出现巨大的混乱，我们决定将每个解决方案的所有更新压缩到一个提交中，然后使用几个重基重新构建图片中显示的有点线性的结构。

正如您可能已经猜到的那样，发布，进行重基是一项很大的工作。即使使用了助手脚本(在重基之后重新将分支附加到提交，但需要在新/更改的分支名称发生时进行维护)，我们仍然需要进行重基、修复冲突、重新附加分支并将更改推送回存储库(使用强制推送)。

除了实际工作外，这也是只有有丰富git经验的团队成员才有信心去做的事情。换句话说，那些不那么自信的人抱怨这个程序(我很清楚)。

顺便提一句，我们失去了git的明显优势:不存在更改历史(旧版本也丢失了)。此外，开发人员需要协作并交流对代码的更改。

问题你能推荐任何标签/分支/重基/.解决以下问题的工作流？

• 课程参与者可以轻松地为他们目前正在进行的练习签出最新的解决方案(编辑:当前，用Eclipse中的鼠标进行此操作是首选的方法)。
• 每个练习的解决方案都以一种方便的方式提供(即一次提交)
• 开发人员可以很容易地将修复和更新集成到单个解决方案，以便在此基础上构建的后续解决方案也相应地进行更新。
• 可选更改历史记录被保留。

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

Answer 1

与其将每个“解决方案-xyz-foo”提交作为单独的分支访问，不如将其作为链中搜索的祖先提交来访问。

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

然后，在“rebase-到IMPROVED_COMMIT”之后的签出将生成基于IMPROVED_COMMIT的分支。

看见

git help revisions

如果使用标记而不是分支，则可以使用

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

若要更新引用所有更改的提交的所有标记，请执行以下操作。参见'git帮助过滤器-分支‘。同样，学生可以通过'git签出-b TAGNAME‘直接从标记名获得分支，并且历史记录也是可用的。

Answer 2

因此，听起来就像在链的中间进行外科重基，以修复一些提交，然后再对(以前)后续提交的另一个重基--到新修复的提交上。因此，我对评论"...Even与一个助手脚本(在重基之后重新将分支附加到提交，但在新/更改的分支名称发生变化时需要维护).“感到困惑。这看起来(可能)就像重基一样简单--在更新的提交上，所以没有必要为新的/更改的分支名称维护它--所有这些东西都是通过重基进行的，不是吗？