git（+ LaTeX）分支/合并工作流程

Question

当前工作流程

我使用git控制版本LaTeX中写的论文。 我想改进目前次优的git工作流程，因为它需要太多的合并（即需要时间+它会污染日志历史记录）。

目前，我的工作流程如下：

• 我承诺master分支＆＃34;最终确定＆＃34;仅发布（即当我向我的主管发送当前未破损的工作版本时）;
• 这些提交来自develop分支，该分支聚合了多个feature/x分支并包含预发布补丁。
• 几个feature/x，对应于我论文的各个部分，例如：
  • feature/state-of-the-art
  • feature/conclusion
  • feature/page-layout
  • feature/global-settings

在每个feature - 分支中，我主要只更改一个文件（例如part/SotA.tex为第一个分支）。然而，我喜欢与多个分支合作，因此我更容易跟踪在这个或那个部分/主题上完成的工作。

缺点

然而，这个工作流程有一些缺点，我想整理出来：

• 要概述我的工作，我必须将每个feature/x分支合并到develop。这让我做了很多合并提交，污染了我的历史。实际上，我的工作流程实际上看起来非常像这样（d3，d4和d5就在这里，以便让我对我的工作进行全局概述）：
  

• 同样，如果我想导入在另一个分支中完成的修改（例如加载包），我必须将develop分支合并回每个{{1}分支：
  

问题

因此，我希望能够：

1. 与其他feature/x分支机构共享feature/n分支的更改
2. 能够概述feature/x分支上剩余的工作（而不是feature/n + $git checkout master）

没有这么多合并。
我知道我可以使用更少的分支，但是，如上所述，它们对我有用，我想保留它们。我认为$git merge feature/n可能是一个解决方案，但我并没有掌握rebase -p足以弄清楚如何继续 - 因为每个git分支源于并合并到{{1} }。

注意：我是这个工作流程中唯一的提交者，因此我可以根据需要重写历史记录。

Answer 1

  

为了概述我的工作，我必须将每个feature / x分支合并到develop中。

提交没有任何神圣之处。最简单的可能是使用可废弃的分支名称进行概述，

git checkout -B overview develop; git merge feature/x feature/y feature/z

然后当你完成放弃它时，请查看其他内容。

  

同样，如果我想导入在另一个分支中完成的修改（例如加载包），我必须将develop分支合并回每个feature / x分支

Naaahh。我将加载的软件包与子模块一起工作，不再担心它，为这些东西设置一个“软件包”仓库，只记得git add提交之前设置的当前软件包，或者没有您可以git rm -r packages; git checkout develop -- packages复制所需版本的子模块。对于其他更改，小型偷渡式修复等等，通常足够git cherry-pick甚至git cherry-pick --no-commit都是您真正想要的。