-1

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).
enter image description here

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. )

DarkTrick
  • 2,447
  • 1
  • 21
  • 39
  • Besides attempting to control the graph (to keep it simple to draw), you could attempt to control the graph-drawing software (to convince it to draw simply). To get started on that—it's a big topic!—see [Pretty Git branch graphs](https://stackoverflow.com/q/1057564/1256452). – torek Dec 20 '22 at 01:28
  • 3
    This question is better suited to [programmers.se] than Stack Overflow. We disallow questions that are open to opinion (and for the most part things that are more workflow-focused than technical), whereas "best practice" &c are explicitly allowed there. – Charles Duffy Dec 20 '22 at 02:37
  • @CharlesDuffy: Is there a possibility to easily move it over there including comments and current answers? – DarkTrick Dec 21 '22 at 01:47
  • That has to be done by a moderator -- you can raise a flag asking one to do so. – Charles Duffy Feb 03 '23 at 19:28

2 Answers2

1
  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.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • I cannot disagree more strongly; if you don't have merge commits you don't know when things hit main, and when you force a rebase, you lose the ability to determine that something was developed correctly and corrupted during rebase or merge -- which can be important for accurate post mortem of how a bug came to be introduced. – Charles Duffy Dec 20 '22 at 02:41
  • Granted, this is a place where git is broadly inferior to its predecessors -- BitKeeper let you have it both ways, maintaining a visually clean timeline but still being able to drill down. – Charles Duffy Dec 20 '22 at 02:42
  • @CharlesDuffy There are merge commits with main, M1 and M2 above. – Schwern Dec 20 '22 at 07:08
0

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.

tymtam
  • 31,798
  • 8
  • 86
  • 126