git - 相关变更集的 Git 工作流程

Question

我正在研究两个非常相关的变更集，其中第一个变更引入了某种功能——我们称之为库变更集——第二个使用它——我们称之为特性变更集。

由于开发工作流程，最好将这两个变更集显示在 origin/master git 分支中作为两个独立且完整的提交 -库提交和功能提交。我可以在私人分支机构或本地大师中做任何我想做的事情。此外，显然 origin/master 分支不允许重写历史记录。

代码的工作方式，库变更集和功能变更集从不涉及相同的文件，但它们存在于同一个 repo 中，因此尽管两者之间没有冲突的可能性，但它们共享相同的历史记录和提交顺序。

在我完全适应它们之前，我也不必将我的更改推送到原点。

在理想的世界中，我会首先完成并提交库更改，将其推送到 origin/master，然后处理 *feature、测试和推送。但是，在功能开发过程中，库实现的某些问题可能需要重新访问库变更集。而且，见上文 - 最好不要为library再次提交，而是修改原始提交。git commit --amend只有当我没有提交功能更改时才有可能，并且在存在与library无关的功能更改时也会很尴尬。

这是我现在使用的工作流程，但它是最好的工作流程吗？似乎应该有一个更清洁的方法......

1. 从master分支库分支，一直工作到满意为止，根据需要经常提交
2. 一旦对库感到满意，将所有提交压缩为单个变更集提交
3. 从库中分叉功能分支，在库上工作，根据需要提交
4. 如果需要更改库代码：
   • 在功能分支上，git reset向库变更集提交
   • git stash
   • git checkout 图书馆分馆
   • git commit --amend在图书馆分支上进行更改
   • 删除原始特征分支
   • 从库中分叉新功能分支
   • git stash pop在新的分支
   • 根据需要重复步骤 4

上面的顺序似乎有效，但我觉得它容易出错并且有些笨拙。

有没有更好的方法来实现我的目标？

标签： git

Answer 1

这是最好的开发工作流程不能很好地匹配最佳演示序列的情况之一：您正在处理相互关联的更改，应该解开相互关系并进行组织以进行演示，但这与他们的发展如何运作。这个

在我完全适应它们之前，我也不必将我的更改推送到原点。

是有效载荷报价。推送就是发布，你正在构建一个要发布的作品。你的初稿笔记杂乱无章，不完整，没有顺序，这很正常。以任何对您有意义的顺序和结构完成您的初稿工作，然后使用交互式 rebase 和cherry-pick 来构建您的发布提交系列。

对于彻底的探索性工作，只需在一个分支上完成所有工作，根据需要使用 rebase-and-pick 方法将大块重组为私有 I-think-this-is-{library,feature}-code 分支以获取自己的利益. 有关如何为此使用 rebase 和 cherrypick 的更长讨论，请参见此处，这非常简单。