git（+ LaTeX）分支/合并工作流程(git (+ LaTeX) branching/merging workflow)

 当前工作流程 
 
 我正在使用git来控制我在LaTeX编写的论文。 我想改进我目前次优的git工作流程 ，因为它需要太多的合并（即需要时间+它会污染日志历史记录）。 
 
 目前，我的工作流程如下：  
 
 
 
 我承诺只master分支“最终确定”的版本（即当我向我的主管发送当前未破坏的我的工作版本时）; 
 
 
 这些提交来自一个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分支合并回每个feature/x分支： 
  
 
 
 
 题 
 
 因此，我希望能够 ： 
 
 
 
 与其他feature/x分支共享feature/n分支的更改， 
 
 
 能够概述我在feature/n分支上的工作（而不是$git checkout master + $git merge feature/n ） 
 
 
 没有这么多合并。 
 我知道我可以使用更少的分支，但是，如上所述，它们对我有用，我想保留它们。 我认为rebase -p可能是一个解决方案，但我并没有掌握git足以弄清楚如何继续 - 因为每个feature/x分支源于并合并到develop 。 
 
 
 注意：我是这个工作流程中唯一的提交者，所以我可以按照自己的意愿重写历史记录。 

Current workflow
 
I'm using git to control-version my thesis written in LaTeX. I'd like to improve my currently sub-optimal git workflow, since it requires too many merges (i.e. it takes time + it pollutes the log history).
 
Currently, my workflow is the following: 
 
 
 
I commit to master branch "finalized" releases only (i.e. when I send my supervisor a current not-broken version of my work);
 
 
These commits come from a develop branch that aggregates several feature/x branches and contains pre-release patches.
 
 
Several feature/x, corresponding to the various parts of my thesis, e.g.: 
  
 
   
feature/state-of-the-art
 
   
feature/conclusion
 
   
feature/page-layout
 
   
feature/global-settings
 
  
 
 
In each feature-branch, I mostly change one file only (e.g. part/SotA.tex for the first branch). Yet I like to work with multiple branch, so that it's easier for me to keep track of work done on this or that part/topic.
 
 
Drawbacks
 
This workflow however has some drawbacks I'd like to sort out:
 
 
 
To have an overview of my work, I have to merge each feature/x branch into develop. This makes me do a lot of merge commits that pollutes my history. Indeed, my workflow looks actually rather like this (where d3, d4, and d5 are just here to enable me to have a global overview of my work):
 
 
 
Similarly, if I want to import modifications done in another branch (e.g. loading a package), I have to merge back the develop branch into each feature/x branch:
 
 
 
 
Question
 
Thus, I'd like to be able to:
 
 
 
share changes of the feature/n branch with other feature/x branches,
 
 
be able to have an overview of my work remaining on feature/n branch (instead of $git checkout master + $git merge feature/n)
 
 
without so doing so many merging.
 I know I could use less branches, but, as explained above, they are useful to me and I'd like to keep them. I think rebase -p could be a solution, but I'm not mastering git enough to figure out how to proceed - since each feature/x branch stems from and merge into develop.
 
 
NB: I am the only commiter in this workflow, so I can rewrite history as I want.

原文：https://stackoverflow.com/questions/41511776