Marco Eckstein
Marco Eckstein

Reputation: 4758

How to have one branch with full history and one branch with squashed history?

I have are requirement that the main branch has only one (potentially big) commit per issue ID. However, to confirm to the best practice of small commits, I also need to create and keep(!) multiple small commits per issue ID.

I have already found an OK solution (I think):

  1. Create a feature branch my-feature-branch from main.
  2. Make multiple small commits to my-feature-branch.
  3. In main: git merge --squash my-feature-branch
  4. main now has the big commit, automatically with a message referring to the small commits, so you can always "zoom in" to the detailed history if needed.
  5. Keep my-feature-branch and stop working on it.
  6. Create a new feature branch my-feature-branch-2 etc.

However, it would still be nicer to not need multiple feature branches for this. It would be nice to just have one extra branch, e.g. main-detailed. The problem is that whenever I git merge --squash main-detailed to master, Git tries to merge the full history of main-detailed, because it does not know that some of that history had already been merged via previous merge --squash commits. Is it still possible somehow to implement the desired workflow?

Upvotes: 2

Views: 161

Answers (1)

j6t
j6t

Reputation: 13617

I will assume that main (with the squashed commits) is some sort of "official" view that must not show the details in the history, and that the detailed branch is a "personal" branch that lets you investigate a more useful history for developers.

I suggest that you keep the following history:

0--------A-----------D     <-- main
 \        \           \
  a--b--c--o--d--e--f--o   <-- detailed

The two branches have a common base 0. You develop on branch detailed. The first feature consist of commits a, b, c. When it is ready, you switch to main, then

git merge --squash detailed

to create commit A. Then you switch back to detailed and

git merge main

This does not introduce any new changes, because the tips of the two branches must be equal at this point. You repeat the procedure for the feature consisting of commits d, e, f to create the squash-merge commit D.

The effect of merging main into detailed is that the squash-merges will not consider the already merged feature commits. When you look at the history of main, the detailed commits are invisible, but when you look at the history of detailed, you see all commits, including those in main.

Upvotes: 3

Related Questions