git (+ LaTeX) branching/merging workflow

Question

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:

1. share changes of the feature/n branch with other feature/x branches,
2. 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.

Answer 1

To have an overview of my work, I have to merge each feature/x branch into develop.

There's nothing sacred about a commit. Easiest is probably to make your overviews with a discardable branch name,

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

and then when you're done looking just abandon it, checkout something else.

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

Naaahh. I'd do the loaded packages work with a submodule and just not worry about it any more, have a "packages" repo for that stuff and just remember to git add the current packages set before committing, or to do it without submodules you could just git rm -r packages; git checkout develop -- packages to copy across the version you want. For other changes, small drive-by fixes and such, often enough git cherry-pick or even git cherry-pick --no-commit is all you really want.