相关变更集的Git工作流程

Question

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

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

代码的工作方式，库更改集和功能更改集永远不会接触相同的文件，但是它们位于相同的存储库中，因此尽管两者之间没有冲突的可能性，但是它们共享相同的历史记录和提交序列。

在我完全适应两个变更之前，也不必将变更推送到原始位置。

在理想的世界中，我首先要完成并提交 libary 更改，将其推送到源/主服务器，然后再进行*功能，测试和推送。但是，在 feature 开发期间， library 实现的某些问题可能需要重新访问库变更集。而且，请参见上文-最好不对库进行另一次提交，但修改原始提交。 git commit --amend仅在我未提交功能更改时才有可能，并且在存在功能更改且与 library 。

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

来自master的
1. Fork library 分支，对其进行处理直至满意，并根据需要进行多次提交
2. 对库感到满意之后，将所有提交压缩为单个变更集提交
3. 库中的功能分支，在库中工作，根据需要提交
4. 如果需要更改库代码：
   • 在 feature 分支上，git reset到 library 变更集 提交
   • git stash
   • git checkout 库分支
   • 进行更改，git commit --amend在库分支
   • 删除原始的功能分支
   • 从库中派生新的 feature 分支
   • git stash pop在新分支中
   • 根据需要重复步骤4

上面的序列似乎可行，但是我觉得它容易出错并且有些笨拙。

是否有更好的方法实现我的目标？

Answer 1

在以下情况中，最佳开发工作流程与最佳演示顺序并不匹配：您正在进行相互关联的更改，应该解开并组织相互之间的关联以进行演示，但这并不能满足要求与他们的发展如何息息相关。这个

  

在我完全适应两个变更之前，也不必将变更推送到原始位置。

是有效负载报价。推送即发布，您正在构建要发布的作品。您的初稿音符杂乱，不完整且顺序混乱，这很正常。按照您认为合适的顺序和结构进行初稿工作，然后使用交互式rebase和cherry-pick构建您的for-publication提交系列。

对于直接的探索性工作，只需在单个分支上完成所有工作，就可以根据自己的需要将大块重新组织起来，并且可以使用rebase-pick方法转换为私人I-think-this-is {library，feature}代码分支。有关如何使用rebase和cherrypick的详细讨论，请参见here，这非常简单。