I'm using feature/develop/test/production branches, where merges happen from left to right. For all branch merging I'm using non-fast-forward merge. Reason: I'd like to know when new features were added to the specific branch.

Problem:

The merge graph can become quite unreadable (see below).

To make the graph more readable I'd like to keep it as straight as possible.

Though-of Solutions:

1. My idea was be to use fast-forward merging for develop->test and test->production. However, that way git does not seem to provide information on when the specific merge happened. Which is bad from a documentation perspective.

2. I also thought of fast-forward merging with a label for every merge. But I'm not sure if this is what labels are made for.

Question

Is there a way to keep merge-logs while not letting the git graph become unreadable/complex? ( edit: I'm using gitk, btw. )

CodePudding user response：

1. Avoid commits directly to main.
2. Always update branches with rebase.
   • This includes git pull. Configure pull.rebase to merges.
3. Require branches be up to date before merging.
4. Put a summary of the branch and metadata (issue #, etc) about the branch in the merge commit.

"Update" merges have no historical value and only serve to complicate the history. Avoid them.

Requiring branches to be up-to-date before merging means what you test in the branch is what will be merged into main.

The result is "feature bubbles" like so.

A -------- M1 --------- M2 [main]
 \         /\         /
  1 - 2 - 3  4 - 5 - 6

The history is linear, yet preserves the grouping of commits into branches. You can look at just the merge commits with git log --first-parent.

CodePudding user response：

The two most popular solutions to this problem afaik are:

• rebasing - not great for shared feature branches (i.e. multiple people working on the same branch) as it modifies the source branch's history
• squashing upon merge - not great for long lived feature branches as the commit in the target branch is different to the the sources commits and reusing the source branch can get messy.
  • GitHub's Squash and merge your commits:

    You can use squash and merge to create a more streamlined Git history in your repository.

  • Azure DevOps' Merge strategies and squash merge:

    Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch. Squash merge commit doesn't have a reference to the topic branch, it will produce a new commit, that contains all changes from the topic branch. Furthermore it is recommended to delete the topic branch to prevent any confusion.