Is there any way to ignore local commit history when merging and pushing to remote?

Issue

We want to have per-developer branches on git. In other words, developers would branch off of the “development” branch and create a local “feature” branch of their own to work on.

When they feel satisfied with their work, they can swap over to devel, make sure they have the latest files, and then merge in their “feature” branch and push the result to origin after dealing with any conflicts.
However, there is a problem – this makes the commit history very messy.

If you do git log --graph, the “feature” branches don’t show up, which is what we want. However, every single commit that developer made now shows up on the devel branch. That’s ugly. If there’s 10 developers and each one made 30 commits to their feature branch before they all got merged into devel, devel now shows a history of 180 commits for a total of 6 features. It would be nicer if the history just showed messages for the 6 merges into devel.

Is there some way to avoid making the history “messy” and ignore the history of a local branch when merging? Or is this just fighting git too much?

I realize this might sound odd, but they very much dislike the idea of all those objects ending up on the remote repo.

Solution

If you do git log, the “feature” branches don’t show up, which is what we want. However, every single commit that developer made now shows up on the devel branch.

git log, by default, shows you a linear version of history that is simple and false. Git history is not linear. Branches really branch.

Instead of this…

A - B - C - D - E - F - G - H [devel]

Your history really looks like this.

A ---------- E ----- H [devel]
 \          / \     /
  B - C - D    F - G

You can see this with git log --graph or a Git visualization tool like Gitup.

Each of those “feature bubbles” are the commits from each branch. Using the true history you can see what commits were developed as part of one feature. While this might seem “messy”, this is important to understanding the code. Its especially useful along with git blame.

Is there some way to avoid making the history “messy” and ignore the history of a local branch when merging? Or is this just fighting git too much?

My advice is to get used to it, and to learn how to navigate it. For example, git log --merges will only show the merge commits. A good Git visualization tool will help a lot.

The other is to encourage developers to clean up their branches before committing. If you have a lot of commits that are “typo fix” and “oops” and “broke the tests” these are of little value going forward. They can use git commit --amend to change the previous commit, and git rebase -i “fixup” to merge existing commits together. This ensures all commits are of some consequence.

If you really want to, you can do a “squash merge”, git merge --squash. Rather than retaining the complete commit history this smashes all the changes and all the commit messages in the branch into one commit.

While this produces a “clean” history, it loses a lot of granular information about how the code was developed. If there are, for example, 30 commits in the branch and you do a git blame to understand some code you’ll get the commit messages for all 30 commits with no way to know which one applies to the code.

What you see as “messy” is valuable insights into why the code was written the way it is. This is gold for anyone working with the code down the line. Once smashed together it can never be recovered.

Answered By – Schwern

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published