5 ms·

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 c

• masklinn 5y ago
  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.
  • Hello71 5y ago
    https://github.com/mhagger/git-when-merged https://github.com/mhagger/git-when-merged edit: also https://stackoverflow.com/questions/8475448/find-merge-commit-which-include-a-specific-commit https://stackoverflow.com/questions/8475448/find-merge-commi..., and also github shows this (but only for github PRs, not other merges)
  • nemetroid 5y ago
    > 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.
    • masklinn 5y ago
      > It encodes the necessary information in the commit graph A bog-standard merge already does that.
• rzimmerman 5y ago
  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.
• tomerv 5y ago
  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.
• nemetroid 5y ago
  GitLab offers this in the web UI. Even Azure DevOps does. GitHub apparently doesn’t, though.
  • metaltyphoon 5y ago
    GitHub is weird. Even their rebase workflow works differently than git by creating a new hash :/
    • TimWolla 5y ago
      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).
      • jlokier 5y ago
        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.
        • tome 5y ago
          FTI: "git rebase -S" signs the commits.
• taberiand 5y ago
  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.
  • rocqua 5y ago
    > 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.
    • taberiand 5y ago
      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.
• Too 5y ago
  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.
  • masklinn 5y ago
    > 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.
• TomSwirly 5y ago
  There's no argument for any other method, really.