2

I found that keep merge in the commit history is not useful. Instead it would be more neat if I keep the commit history when doing merge. Like this post mentioned Keep commits history after a 'git merge'

Because I notice that in github, when user accept a pull request, usually they would not create a new merge commit rather than just keep the commit history. So I just wonder what is the best practise for merge ?

Community
  • 1
  • 1
zjffdu
  • 25,496
  • 45
  • 109
  • 159

2 Answers2

7

There is no "best practice" here. The choice is yours.

Some people keep a merge commit, even for a fast forward, because it keeps a very good record of when a branch was completed. These people prefer "complete and accurate" history over a "clean" history.

Some people avoid merge commits, even rebasing their branches, because it keeps the history easier to read. These people prefer "clean" history over "complete and accurate" history.

Most people choose a middle ground, where small changes are rebased and squashed before making them public, which makes each branch clean. The branches are then merged as normal, to preserve the complete and accurate history, at least for the big picture.

Myself, I prefer to use merge --no-ff when completing a feature branch, and I lean towards "accurate" over "clean", but I try to keep the noise down with squashes and rebases here and there.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
0

In addition to what @Dietrich Epp said, i'd like to stretch that depending on what flow you're using, merge commits can prove useful or not.

For example, I use a Feature Flow, where a Jira ticket must be a feature branch, a feature branch always leads to a Pull Request, and a PR is merged in development (and then master) with a squash strategy git merge --squash, which takes all PR's commits and squash them into a single commit. Therefore, I feel no need for Merge commits, since I know that every commit in development/master is a PR. On the other hand, if I allowed multiple commits in PRs, to keep the project history more detailed for instance, I could use a merge strategy git merge --no-ff to be able to see clearly in my history when feature were merged.

Finally, you could use git log --no-merges to read a clean history of your commits, or git log --merges to only see the merges.

theFreedomBanana
  • 2,462
  • 2
  • 22
  • 29