Merge a branch, but dont fill gitk with noise BUT dont lie about where it came from

Question

Im' probably doing this wrong or misunderstanding something here but basically I do not want to fill our master branch with noise but i do not want to lie about my history.

So we have a master branch and a dev branch

In this case we also have a feature branch full of both important and seemingly unimportant (commiting for the day etc)

I merged feature branch onto the dev branch because i do not mind the noise on the dev branch. however now that i am merging dev branch onto master, i would rather not have all that noise from my feature branch.

I thought merge --squash dev_branch was the answer but that seems to act as if i had a sudden flash of brilliance and did all that work in one night with absolutely no reference to the fact it was a merge and in gitk there is no mention of the feature branch at all.

I want to bring in the change so that in gitk all you would see is "merged feature" or "merged dev_branch" but without all the noise underneath

I could use git rebase on the dev_branch to clean up the commits made from feature branch, this way i could still keep the changes as they were in feature without any lies and prettify it in dev_branch...but this seems wrong too

So far the best solution i have come up with is to do git merge --squash dev_branch

and just make the comment "Look at feature branch for more detailed history"

Am i going about this the wrong way? should i really be worried about "noise" can you just collapse changes made under a certain branch?

So its not quite Git: merge all changes from another branch as a single commit

Answer 1

I sometimes use the following workflow, which might suit you:

1. I work in my own repo on a local feature branch (that is not pushed).
2. I pull changes to master frequently.
3. Every now and then I rebase my feature branch on master. If I feel like it, I do it interactively and fix up the history.
4. When the feature is finished, I do a final rebase, and then I merge to master with --no-ff to force a merge commit.

The end result is a history that contains a merge commit, is easy to follow, but still clearly demonstrates that logically separate work has been done in a branch.

|
|
*   merge commit
|\
| \
|  *
|  |
|  *
|  |
|  *
| /
|/
*   common ancestor
| 
|

You also get a single merge commit that can be used to git revert the whole feature if you wish.

Answer 2

I've settled on using:

gitk --first-parent

From the docs:

--first-parent :: Follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.

Occasionally I'll have long running feature branches, that have to merge (just merge, no squash nor rebase) changes from the mainline.

gitk --first-parent is pretty good. Not perfect, but gets the job done.

Answer 3

Have you already pushed the dev branch and thus shared it with others?

If not, an interactive rebase will do an excellent job

git checkout devbranch
git rebase -i master

Git rebase will give you the opportunity to clean up your history by edit commits, squash them together, split them or even skip some.

The above will end up putting the commits of devbranch in a straight history after master. If you feel that is too much "lying" then you can rebase devbranch on its own base, so you can rewrite history but still keep it as a branch starting at the same place as before

git merge-base master devbranch
git rebase -i <hash output of previous command>