Hacker News Reader

Comment by ufo | Hacker News Reader

In my organization we kind of do this. We use one merge commit per pull request, without squashing. However, we also rebase before merging, which results in a commit graph that looks like a cactus:

      o-o-o   o-o   o-o-o
     /     \ /   \ /     \
    o-------o-----o-------o-->

View on HN

I also prefer this method - rebase and force a merge commit. It’s pretty much the grouping functionality that the author wants. You can tell a short story or break a merge into a couple parts, and bisect + revert work. You can also link each merge with a merge/pull request and a ticket. Also, an occasional quick fix commit to master works fine and makes sense. Sometimes a merge without a rebase makes sense as long as it doesn’t make the graph too confusing. Different workflows work for different teams, but I like this one.

The "semi-linear merge" (as Azure DevOps calls it) is our preferred merge approach as well, though reasonable cases can be made for alternative merges depending on circumstance, e.g., an old version hotfix merge into master is of course done as a regular merge.

In addition, if people are feeling charitable, the branch will be cleaned up prior to merge with an interactive rebase to squash out "Wip" commits and hopefully leave a nice clear set of self-contained commits that provide a logically separated view of the work that went into the change.

> In addition, if people are feeling charitable, the branch will be cleaned up prior to merge with an interactive rebase

If you're not doing that, might it not be better to squash? The point of not squashing is to preserve valuable granular commits. If you have WIP commits, those don't have much value.

I suppose it depends on how clean the feature branch is. Personally, I have horrible commits, knowing I will clean them up later.

Interactive rebase allows you to optionally squash a commit down (or edit or otherwise manage them). The idea being that you can keep the important commits that express the purpose of the branch while cleaning up those that are not important for that purpose.

This is the best option in my opinion. You can also "optimize" by doing the forced merge only for branches that have 2+ commits. That way, if most of your branches have a single commit you won't have many useless merges. The branches with multiple commits will still be visually grouped.

GitLab offers this in the web UI. Even Azure DevOps does. GitHub apparently doesn’t, though.

GitHub is weird. Even their rebase workflow works differently than git by creating a new hash :/

A rebase always creates a new hash, because the commit hash is a hash over the contents of the commit. This contents include, among others, the parent commit(s) and the time of committing (which in case of a rebase will be different than the time of authoring).

I think that's not what the GP means.

"git rebase" doesn't create a new hash if there's no change as a result of the rebase. But GitHub's PR rebase button always creates a new hash even if there is no reason to. (Its PR merge button does not do this; it will merge a one-commit PR without creating a new commit).

To add to the inconsistencies, GitHub doesn't sign the new commit when using the rebase button so it doesn't show up with the green "verified" icon - even if there was no need for a new commit anyway. Yet when using the merge button it does the opposite - if it doesn't need a new commit, your signed PR commit is merged to the main branch and shows as verified, and if it does need a new commit GitHub signs it (if the PR commit was signed) so it still says "verified" (even though it's really GitHub's key that was used, not the author's).

For this reason, when I merge PRs I avoid the GitHub UI, and use "git rebase -S" locally followed by "git push". This does what the PR rebase button should do.

FTI: "git rebase -S" signs the commits.

Sure but that's not really helpful, the only thing it does is avoid breaking history visualisation tools which tend to deal very badly with "wide" histories.

For instance one of the biggest annoyances with git is it's a pain in the ass to find the the merge of a commit into the mainline (aka the next child with more than one ancestor… probably), which can make it difficult to go back from a commit to a PR unless it was a single-commit pull request.

> Sure but that's not really helpful, the only thing it does

It encodes the necessary information in the commit graph, without introducing a completely new concept (commit groups). It’s true that Git doesn’t give you the tooling to get that information out of the box, though.

> It encodes the necessary information in the commit graph

A bog-standard merge already does that.

https://github.com/mhagger/git-when-merged

edit: also https://stackoverflow.com/questions/8475448/find-merge-commi..., and also github shows this (but only for github PRs, not other merges)

For visual history this seems like a nice approach. In a large organization, can it be done atomically or is there a risk someone else merges before you during the rebase?

But I believe this also suffers from the problem described in OP where you can't tell if HEAD^ (or any parent) is from master or from feature branch.

> In a large organization, can it be done atomically or is there a risk someone else merges before you during the rebase?

It can be done atomically by having a tool perform the rebase and merge, and never merging anything by hand.

That’s necessary to implement the “not rocket science” rule anyway.

There's no argument for any other method, really.

Reply on news.ycombinator.com